Enhanced title processing arrangement

ABSTRACT

Methods, apparatus, and data structures embodied in computer-readable media are provided for facilitating access to a service in a network. Title materials are received which include one or more of a first title object, a component of the first title object, or a reference to the first title object. The first title object is a first digital bearer instrument representing at least one right relating to the service, the first title object including a reference to the service. A second title object is identified with reference to a service registry and the reference to the service included in the first title object. The second title object is a second digital bearer instrument with which redemption of the at least one right relating to the service and represented by the first title object may be effected.

1 CROSS REFERENCE TO RELATED U.S. PATENT APPLICATIONS

An Application Data Sheet is filed concurrently with this specificationas part of this application. Each application to which this applicationclaims benefit or priority as identified in the concurrently filedApplication Data Sheet is incorporated by reference herein in itsentirety and for all purposes.

This application claims priority under 35 U.S.C. 119(e) to U.S.Provisional Patent Application No. 60/746,032 (Attorney Docket No.API1P008P) filed Apr. 29, 2006, the entire disclosure of which isincorporated herein by reference for all purposes.

The present application also relates to subject matter described in thefollowing applications, each of which is incorporated herein byreference in its entirety for all purposes.

U.S. patent application Ser. No. 10/439,629 (Attorney Docket No.API1P004X4) filed May 15, 2003, which is a continuation in part of U.S.patent application Ser. No. 10/232,861 (Attorney Docket No. API1P004)filed Aug. 30, 2002 and claims priority to U.S. Provisional PatentApplication No. 60/380,787 (Attorney Docket No. APLD-P001-P) filed May15, 2002, U.S. Provisional Patent Application No. 60/407,466 (AttorneyDocket No. APLD-P002-P) filed Aug. 30, 2002, and U.S. Provisional PatentApplication No. 60/407,382 (Attorney Docket No. APLD-P003-P) filed Aug.30, 2002.

U.S. patent application Ser. No. 11/146,399 (Attorney Docket No.API1P005) filed Apr. 29, 2005, and claims priority to U.S. ProvisionalPatent Application No. 60/649,929 filed Feb. 3, 2005 (Attorney DocketNo. API1P005P).

U.S. patent application Ser. No. 11/118,608 (Attorney Docket No.API1P006) filed Jun. 3, 2005, and claims priority to U.S. ProvisionalPatent Application No. 60/649,928 filed Feb. 3, 2005 (Attorney DocketNo. API1P006P).

U.S. patent application Ser. No. 11/096,284 (Attorney Docket No.API1P002X1) filed on Mar. 30, 2005, which is a continuation in part ofU.S. patent application Ser. No. 10/873,841 (Attorney Docket No.API1P002) filed on Jun. 21, 2004, which is a continuation-in-part ofeach of U.S. patent application Ser. No. 10/439,629 (Attorney Docket No.API1P004X4) filed on May 15, 2003, U.S. patent application Ser. No.10/440,286 (Attorney Docket No. API1P004X3) filed on May 15, 2003, U.S.patent application Ser. No. 10/414,830 (Attorney Docket No. API1P004X2)filed on Apr. 15, 2003, U.S. patent application Ser. No. 10/414,817(Attorney Docket No. API1P004X1) filed on Apr. 15, 2003, and U.S. patentapplication Ser. No. 10/232,861 (Attorney Docket No. API1P004) filed onAug. 30, 2002.

U.S. patent application Ser. No. 11/645,139 (Attorney Docket No.API1P009) filed on Dec. 22, 2006, which claims priority to U.S.Provisional Patent Application No. 60/755,750 (Attorney Docket No.API1P009P) filed Dec. 29, 2005, and U.S. Provisional Patent ApplicationNo. 60/765,388 (Attorney Docket No. API1P009P2) filed Feb. 2, 2006.

2 COPYRIGHT NOTICE

A portion of the disclosure of this patent document may contain materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever. The following notice shall apply to this document:Copyright 2007, Navio Systems Inc.

3 BACKGROUND OF THE INVENTION 3.1 Field of the Invention

The present invention provides architectures, systems, methods, andsoftware for providing and managing rights using digital bearerinstruments that express at least one right. The invention hasapplications in the fields of computer science and electronic businessmethods.

3.2 The Related Art

The Internet has become an efficient mechanism for globally distributingdigital content, such as documents, pictures, music, and other types ofdigital content. Information can now be transmitted directly andinstantly across the Internet from the content owner to the contentbuyer, without having to first convert it into physical form, such aspaper documents, compact disks, photographs, etc.

However, the advantage of easy digital communication has also alloweddigital content to be easily pirated by just about anyone with acomputer and Internet access. The combination of high-speed broadbandInternet access, digital content compression software (which reduces thesize of digital content files), peer-to-peer file trading networks(which allows users to post content files), and lack of a viable digitalrights standard, has caused content owners to lose control of theircontent. Consequently, content owners are experiencing a loss ofpotential revenue.

Existing systems that attempt to provide confidence between buyersinclude escrow agreements, third party confirmations, third partyappraisals and other similar techniques. These systems are slow andcomplex, and they do not provide the content user with sufficientconfidence that the buyers and sellers are not illegally replicating thecontent or otherwise attempting to sell pirated copies of works.

4 SUMMARY OF THE INVENTION

According to a first class of embodiments, methods, apparatus, and datastructures embodied in computer-readable media are provided forimplementing a workflow in a network. The workflow is a sequence ofoperations relating to a set of services deployed in the network. Titlematerials are received which include one or more of a title object, acomponent of the title object, or a reference to the title object. Thetitle object is a digital bearer instrument specifying the workflow andrepresenting at least one right relating to implementation of theworkflow in the network which may be redeemed by presentation of thetitle object to a title-enabled device or process operating in thenetwork. Upon validation of the title object, the workflow isimplemented in accordance with the at least one right represented by thetitle object.

According to another class of embodiments, methods, apparatus, and datastructures embodied in computer-readable media are provided forfacilitating access to a service in a network. Title materials arereceived which include one or more of a first title object, a componentof the first title object, or a reference to the first title object. Thefirst title object is a first digital bearer instrument representing atleast one right relating to the service, the first title objectincluding a reference to the service. A second title object isidentified with reference to a service registry and the reference to theservice included in the first title object. The second title object is asecond digital bearer instrument with which redemption of the at leastone right relating to the service and represented by the first titleobject may be effected.

According to yet another class of embodiments, methods, apparatus, anddata structures embodied in computer-readable media are provided forfacilitating redemption of rights. Title materials are received whichinclude one or more of a first title object, a component of the firsttitle object, or a reference to the first title object. The titlematerials represent at least one right. A title object template isidentified from among a plurality of title object templates withreference to the title materials. A second title object is dynamicallyassembled using the identified title object template and at least someof the title materials. The second title object is a digital bearerinstrument with which redemption of the at least one right representedby the title materials may be effected.

A further understanding of the nature and advantages of the presentinvention may be realized by reference to the remaining portions of thespecification and the drawings.

5 BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an example of a Title Processing Environment (TPE) andits components.

FIG. 2 depicts three overlapping ecosystems according to an embodimentof the invention.

FIG. 3 is an example of a logical representation of two ecosystemssharing a common component.

FIG. 4 extends the example shown in FIG. 3 to illustrate three users.

FIG. 5 is an illustration of an operating context implemented accordingto a specific embodiment of the invention.

FIG. 6 depicts an example of a Title Resolver and its components.

FIG. 7 is a flowchart illustrating a process for resolving titlematerials according to a specific embodiment of the invention.

FIGS. 8A and 8B are flowcharts showing two alternative title validationprocesses according to specific embodiments of the invention.

FIG. 9 is a schematic diagram of an example of a Service Router and itsconnections to services and applications in accordance with oneembodiment of the present invention.

FIG. 10 is a message flow diagram that illustrates a simple flow exampleintermediated by a Service Router in accordance with one embodiment ofthe invention.

FIG. 11 is a message flow diagram that illustrates a more complex flowexample with a plurality of endpoints in accordance with one embodimentof the invention.

FIG. 12 is a message flow diagram that illustrates a complex flowexample utilizing a plurality of endpoints and Service Routers inaccordance with one embodiment of the present invention.

FIG. 13 is a message flow diagram that illustrates a flow utilizing anadapter as an endpoint in accordance with one embodiment of the presentinvention.

FIG. 14 depicts a simplified user interface to a title manager, shown asan independent overlay window, according to one embodiment of theinvention.

FIGS. 15a-d illustrate examples of a user interface which facilitatesinteraction with title objects according to a specific embodiment of theinvention.

6 DESCRIPTION OF SPECIFIC EMBODIMENTS OF THE INVENTION 6.1 Definitions

The following definitions are used throughout, unless specificallyindicated otherwise:

Authorization A class of materials that are used to provideauthentication and authorization materials when validated by an Identityprovider. In embodiments where SAML is used, a SAML artifact is anexample of authorization materials. DCE Digital Commerce Engine, aproduct of Navio Systems, Inc., of Cupertino, California. Embedded Asoftware representation that is stored within a software container, insuch a manner that the software representation may be uniquelyidentified and optionally removed. SAML artifact A small, fixed-size,structured data object pointing to a typically larger, variably-sizedSAML protocol message. Security indicia An encoding of information thatis used to convey one or more of identity, authenticity, orauthorization. Examples of security indicia include SAML artifacts,id/passwords, digital hashes, Kerberos tickets. Service A service is anapplication program associated with at least one network address andport, which receives and processes request messages and optionallygenerates response messages. A general service description language maybe provided, for example, by WSDL. Service Identifier Document ID,service definition name, or service alias Service endpoint A networkservice Title or title object Bearer-based rights representation suchas, for example, titles implemented by Navio Systems, Inc., ofCupertino, California.

6.2 Overview

Reference will now be made in detail to specific embodiments of theinvention including the best modes contemplated by the inventors forcarrying out the invention. Examples of these specific embodiments areillustrated in the accompanying drawings. While the invention isdescribed in conjunction with these specific embodiments, it will beunderstood that it is not intended to limit the invention to thedescribed embodiments. On the contrary, it is intended to coveralternatives, modifications, and equivalents as may be included withinthe spirit and scope of the invention as defined by the appended claims.In the following description, specific details are set forth in order toprovide a thorough understanding of the present invention. The presentinvention may be practiced without some or all of these specificdetails. In addition, well-known features may not have been described indetail to avoid unnecessarily obscuring the invention.

Aspects of the invention are directed to the creation, ownership,exchange, management, reselling, marketing, bartering, and auctioning oftitles. In this context, a title is an object that may have a number ofelements and attributes including embedded digital content, ownershipattributes, copy permissions, and others as described herein. A titlecan represent the rights to a single piece of digital content or asingle resource, or it can represent the rights to a plurality ofdigital content and resources and in a variety of formats.

One aspect of the invention is the providing of an integrated titleprocessing environment that provides seamless title processing servicesacross a plurality of system and deployment models.

Embodiments of the invention are described with reference to specificapparatus and embodiments. Those skilled in the art will recognize thatthe description is for illustration and to provide the best mode ofpracticing the invention. For example, references are made to computerservers and clients, but in a peer-to-peer network, any computer iscapable of acting in either role. Likewise, reference is made toInternet protocols while any substantially comparable data transmissionprotocols can be used.

6.3 Title Materials

A title object is a digital bearer instrument that expresses at leastone right. Title materials include title objects, portions of titleobjects, for example, such as a specific right definition, a referenceto specific title materials, such as reference to a specific titleobject, a specific right specified by a title object, or a reference toother independently validatable portions of title objects. A stub is oneexample of an independently validatible portion of a title object. Atemplate is an additional example of an independently validatableportion of a title object.

Title materials may include workflow and service specifications,including service interface specifications. In some embodiments, aservice definition is sometimes stored in a tf:Title/Content/Detailelement, or it can be stored in a tf:Stub element.

Titles may express specific operating contexts required to redeemspecific rights expressed by the title. In a first embodiment, there maybe no operating context provided by the title. In an alternateembodiment, a single operating context can be provided by the titlewhich applies to all rights expressed by the title. In still additionalalternative embodiments, there may be a plurality of specific operatingcontexts, each associated with one or more rights or sets of rights.Alternatively, a combination of these approaches may be utilized.

Title materials may also include specific instances of digital bearerinstruments that may not include a specific right. Title materials arepresented to title-enabled processes, computers, and devices, which usethe presented title materials to operate on and/or facilitate redemptionof rights expressed by a title. Titles employed by specific embodimentsof the present invention are related to the title technologies providedby Navio Systems, Inc., of Cupertino Calif.

The creation and use of titles and rights in accordance with embodimentsof the invention can be achieved by those having skill in the art withreference to specific examples which can be found in theabove-referenced International and U.S. patent applications.

6.4 Title Processing Environment

A title expressed right processing environment is a substantiallycomplete environment for the processing of title objects and the rightsexpresses thereby. A title expressed right processing environmentcomprises one or more operating contexts, components, and services thatare combined to produce a customizable method of processing at least oneright expressed by title materials.

A title processing environment (TPE) is an instance of a title expressedright processing environment that defines various computer systems,components, configurations, and/or processing methods necessary toprocess at least one aspect of a title. A specific arrangement ofcomputer systems, components, configurations, and/or processing methodsmay comprise a complete instance of a TPE. Alternatively, a specificarrangement of computer systems, configurations, and/or processingmethods may comprise a specific functional subset of a TPE. Sometimesthis functional subset provides a set of functionality and is called aTPE application.

All required functionality for providing a complete title materialsprocessing system may be provided by a single TPE, by a collection ofTPEs that interoperate, or one or more TPEs that interact with existingsystems and services (collectively called external services).

A specific arrangement of components, configurations, and methods istypically specified using one or more operating context(s).Alternatively, an arrangement of components, configurations, and methodsmay be specified and managed using other means such as staticconfiguration files, lookup tables, and service registry entries. Aplurality of operating contexts may share one or more components,modules, configurations, or method instances. Each arrangement ofcomponents and optional context specifications describes a TPE instance.Optionally, TPEs may be disjoint and have no components orconfigurations in common. Furthermore, a TPE can be integrated with andcoordinate the use of external services. Such TPE implementations can beprovided using the techniques described herein and methods known tothose having skill in the art.

Examples of specified components include core system functionalityrequired to implement the TPE itself, and those components thatimplement features required to make the use and processing of titlematerials commercially successful. Specified components may be providedby one or more TPEs, and may include user interface, application, andtitle processing functions. For example, TPE applications includeWallet(s), My Stuff, and Shopping Cart functions, as well as titleprocessing functions provided by a title transaction system (TTS).

In a typical embodiment, each instance of a TPE combines user interface,service, and workflow specifications with implementation components inthe form of services, components, and user interface elements to producea seamless, repeatable, and secure title processing environment. In morespecific embodiments, a TPE may be deployed using servers, desktop andportable (laptop) computers, mobile devices (including, but not limitedto, cell phones, PDAs, and music players), and embedded devices such asset top boxes, DVRs, and home entertainment controllers such asMicrosoft's Media Center. Portions of a TPE may be deployed on differentsystems in differing ways as determined by the implementationrequirements. In some embodiments, portions of a TPE may be deployed ondisparate systems that cooperate to provide the functions of the TPE.For example, a user interface component and related user-centric titlehandling functions such as Wallet(s), My Stuff, and Shopping Cartapplications may be provided on a user's desktop or handheld, andbackend processing such as title transaction servers and DCEs can beprovided on a logically separate server. In most embodiments, the TPEarchitecture includes a user interface operating on the currently in-usedevice (the device the user is currently using). Alternate embodimentsare envisioned where the TPE operates upon a device other than thecurrently in-use device and communicates the user interface componentsto the currently in-use device using a protocol such as RDP or HTTP.More specifically, the TPE architecture extends title expressed rightprocessing operations to an arbitrary user interface presented upon auser interface device of a user's choice. Implementations of TPEarchitectures, including distributed TPEs can be provided using thetechniques described herein and methods known to those having skill inthe art.

In some deployments, the TPE architecture may be deployed as one or moreapplication programs that operate within an extant processingenvironment such as Windows XP or Java Runtime Environment. In somedeployments, one or more components or functions of the TPE architecturemay be embedded within third party applications present in theseenvironments. Alternatively, portions of the TPE architecture maydirectly embedded within said extant operating system and may be used,in part, to fulfill title expressed right processing requests at theoperating system level. In other embodiments, portions of the TPEarchitecture may serve as the underlying operating system whenimplemented upon specific devices. Such TPEs can be provided using thetechniques described herein and methods known to those having skill inthe art.

In an example embodiment, the TPE is implemented as a desktopapplication. In such an embodiment, the TPE's user interface may beimplemented using a development platform such as Macromedia's Flash MX7, although it may be developed using any commercially availableapplication development platform, including alternative versions ofMacromedia's Flash such as Flash Lite, or alternative developmentplatforms such as J2ME and BREW. In other embodiments, one or moreaspects of a TPE may be configured as a server application. Additionalalternative versions of the TPE may also be developed for specificdeployments. Each of these versions of the TPE architecture may bedeveloped using the techniques described herein, platform specificdevelopment tools such as Windows .NET, commercially available fromMicrosoft, Java from Sun Microsystems, or other developmentenvironments, and methods known to those having skill in the art.

An instance of a TPE may be invoked in several ways. In a firstembodiment, a specific TPE instance is invoked by the user when theyselect a user interface-enabled indicator on a web site or as part of anapplication. In other embodiments, a specific TPE may be invoked whenthe user selects an application link that identifies an instance of auser interface to be run. Alternatively, a specific TPE may be directlycalled by an external applications program or web site, or may bestarted based upon recognition of specific received content. Examples ofthe latter may include starting a specific TPE on the basis of a filetype association, MIME type, or upon receipt and recognition of a title,upon receipt an out-of-band communications media such as e-mail orinstant messaging containing a title. Another example is distribution ofcontent on a network such as P2P in a format that can be recognized andinvoked by client applications such as P2P applications. These files aredistributed in a format recognized by the application. Alternatively, aspecific TPE instance may be started at device startup and may be alwaysrunning. In implementations where TPE functionality is embedded in otherapplications or operating system components, the TPE and its componentsmay be directly called by the applications (such as a media playerlicensing interface) or by operating system components within which theTPE components are embedded. For example, a TPE may be invoked by theMicrosoft Media Player license acquisition page. Alternatively, aspecific TPE may be involved by a file browser such as Windows Explorer.Such TPE invocation methods can be provided using the techniquesdescribed herein and methods known to those having skill in the art.

Still other embodiments include embodiments in which the operatingenvironment is further configured to review an operating context uponpresentation of a title. In more specific embodiments, an operatingenvironment is configured with a title resolver, and service registry,or controller, or other component capable of determining whether theoperating environment can process said at least one right expressed bythe title materials. In still more specific embodiments, the operatingenvironment is configured to determine whether one or more additionalobjects require configuration or instantiation to enable the operatingenvironment to process said at least one right. In yet more specificembodiments, the operating environment is further configured toconfigure or instantiate one or more additional objects required toenable said operating environment to process said at least one right. Asdescribed below, this component is called a Controller or a ServiceManager. In some embodiments, the functions of Controller and TitleResolver and Service Registry are combined into a single component.

According to various embodiments, the present invention provides anarchitecture that enables provision of an extensible applicationsframework that flexibly supports a variety of features and functionalitysupporting title-based rights processing operations. Specifically, thepresent invention provides additional methods of defining and assuringrights processing operating environments to extend the capabilities ofrights processing operating environments in a variety of novel ways.Environments for processing titles and the rights expressed therein havebeen established using systems and methods as described in theabove-referenced International and U.S. patent applications. Theseenvironments are statically defined rights operating environments thatoperate in controlled server environments; the environments areestablished by configuring an arrangement of rights processing systems,and then providing titles that are processed by these systems.

According to some embodiments, additional capabilities have been createdfor rights operating environments. These capabilities permit rightsprocessing environments to be used outside of controlled server-basedenvironments, including operating rights processing environments inwhich one or more portions are formally defined or in whichconfigurations are formally assured against tampering, spoofing, andother Internet ills. Formally defining title processing environmentspermits a title processing environment to determine if it is able toproperly process a redeemed right expressed by at least one title priorto starting the processing of that right. It also eases the burden ofprovisioning title processing environments by system administratorsresponsible for keeping these environments operating. The formaldefinition of an operating environment is sometimes called an operatingcontext. Assurance of title processing environments are technical meansby which the components and configurations which comprise a titleprocessing environment may be determined to be free from tampering orchanges from a known, defined standard. In many cases, assurance isprovided using cryptographic means, such as digital signatures andhashes. Application of these cryptographic means for assurance ofprocessing environments is well understood to those skilled in the art.Some title processing environments may be both defined and assured,meaning that they are formally defined and their components are assuredto be free from tampering or unauthorized changes. Defined, assured, anddefined+assured title processing environments significantly extend thecapabilities of title processing environments by:

-   -   supporting the seamless deployment of distributed title        processing capabilities to untrusted host computing platforms,    -   by permitting efficient identification of whether a specific        title or right being presented for redemption is being processed        by an authentic title processing environment,    -   by permitting efficient determination by the title processing        environment as to whether the specific instance of a title        processing environment is able to process the presented title in        accordance with the specifications of the right, and    -   by providing instructions to the instance of a title processing        environments as to the components required in order to process        the title.

According to some embodiments, portions of a TPE may becryptographically protected against tampering, and are validated andverified using techniques and processes similar to those describedherein prior to use.

Furthermore, in accordance with specific embodiments of the presentinvention, the user interaction with a title processing environment maybe specified and defined in order to assure content providers andmerchant sellers of the user interaction provided during titleprocessing.

6.4.1 Title Processing Ecosystems

Instances of TPEs of the present invention may be operably combined,either within one or more applications, servers, and systems asunderstood by those skilled in the art to form a title processingarrangement. Each arrangement is typically defined as described above.Each title processing arrangement may have one or more users, vendors,and/or customers who interact with one or more aspects of the titleprocessing arrangement to effect business transactions using titlematerials. The set of TPEs, combined with the set of users, vendors, andcustomers who use a particular title processing arrangement to conducttitle-enabled commerce is called an ecosystem. Ecosystems may share oneor more TPEs, users, customers, and vendors.

FIG. 1 depicts three overlapping ecosystems according to an embodimentof the invention. Ecosystems illustrate the logical separation betweenprocessing domains. FIG. 1 illustrates three partially overlappingecosystems (1100, 1200, 1300). The logical separation of processingdomains enables the construction of provider-specific title processingenvironments based upon a set of common components while maintaining anappropriate logical and/or physical separation between the informationbeing processed within each title processing environment. For example, afirst set of ecosystems can be constructed to support the business ofmusic and ring-tone distribution and have as customers the musicindustry, mobile telephony carriers, and their respective customerbases. These ecosystems have common components including applicationssuch as title transactions systems, customer and user applicationsincluding wallets, shopping carts, etc, and have a disparate componentsapplications such as an OTA server (for ringtones) and a music playerplug-ins and applications (for music). This is illustrated in FIG. 2, inwhich two ecosystems (2100, 2200) are shown sharing a common component(2900) of a title transaction system (TTS) application. A second set ofdisparate ecosystems may include a set of public networking companiesproviding title enabled networks, and using title technologies toprovision and provide specific network services. This second set ofecosystems also include common applications, such as a title transactionsystem, and may include additional operating system components such as atitle enabled network stack. The set of users and vendors for thesesecond ecosystems may be disjointed between the networking providerecosystems, and may or may not overlap with the music and ringtoneprovider ecosystems. This is illustrated using FIG. 3, in which twoecosystems (as shown in FIG. 2) support a plurality of users. A firstuser (3300 a) is a participant in ecosystem 3100. A third user (3300 c)is a participant in ecosystem 3200, while a second user (3300 b) is aparticipant in both ecosystems. Vendors and customers may be sharedbetween ecosystems in similar ways.

As shown above, each ecosystems may have one or more instances of thesame or similar components, may share components, and may have the sameor differing users, customers, and vendors. Each ecosystem may haveseparate instances of a common component. In some embodiments, sets ofinstances of a common component may operate together (e.g., in one ormore clusters) to provide redundancy and performance improvements. Thespecification of specific application component instances and thedefinition of their membership in particular ecosystems is providedusing environments and contexts as described herein. Theinteroperability between ecosystems is described herein and is definableusing the components and techniques described herein.

6.4.2 Architecture and Logical Configuration

Referring to FIG. 4, a specific embodiment of a TPE (4100) comprisesoptional one or more operating context(s) (4120), an optional context,application, and component loader component (4130), an optional servicemanager or controller component (4110), an identity provider component(4160), title resolver component(s) (4140), a service resolver andregistry component (4170), a service router component (4150), anoptional communications manager component (4175), optional TPEapplications (e.g. 4180 a/b) such as a title transaction system (TTS)and Wallet applications, at least one user interface (4190), andoptional interfaces to external services (e.g. 4165 a/b).

Operating contexts (4120) are used to define the arrangement of TPEcomponents, the arrangement being managed and made operational bycomponents such as the context, application and component loader (4130)and the service manager or controller (4110). In some embodiments, thecontext, application and component loader, and service manager andcontroller components may be omitted and the configuration of the TPEcomponents statically defined. Various embodiments may combine thefeatures and functions of the context, application, and componentloader, the service manager, and controller components.

A TPE (4100) additionally provides an identity provider (1160) and/or aninterface to one or more external identity providers (e.g. 4165 a/b).The TPE uses the identity provider in numerous ways as described herein.

A TPE further provides one or more title resolver component(s) (4140),service resolver and registry component (4170), and service routercomponent(s) (4150), and an optional communications manager component(4175), which provide infrastructure support for title processing withinthe TPE. In some embodiments, the communications manager functionalityis embodied in a service router, service manager, or other TPE componentthat provides service orchestration, marshalling, and related servicesto the TPE. In other embodiments, the communications/session managementcomponent of the TPE manages the communications between the TPEcomponents. This component is sometimes called a connection manager.Different connection managers may be provided to support differentprotocols, for example, a TPE may simultaneously support a connectionmanager that supports the SOAP protocol, one that supports an RPC overHTTP protocol, and yet another that supports SHTTP. The connectionmanager is preferably implemented as discrete components, but may beimplemented as a single component in some implementations. Thecommunications management component optionally includes the capabilityto orchestrate the completion of one or more services on behalf of theTPE.

The TPE further provides one or more optional TPE applications, such asa previously described TSS and Wallet title-based applications (e.g.,4180 a/b) that provide business functionality, and one or more userinterface components (4190) effective to provide an interface betweenTPE applications and users, customers, and vendors. The user interfacecomponents may also provide user interfaces to other TPE components asrequired.

Specialized implementations of a TPE may be constructed that omit one ormore the above described components, and the functionality of any of thedescribed TPE components may be integrated together with, or deployedseparately from, any other TPE component. For example, an integratedService Resolver and Registry may be combined with a Service Router aspart of a particular TPE application.

6.4.2.1 Base TPE Components and Modules 6.4.2.1.1 Operating Context

According to some embodiments, the present invention provides systems,methods, and software for processing digital bearer instruments inaccordance with configurations specified in at least one operatingcontext. The operating content(s) required may be provided within anexisting operating environment, as part of a title for which a right isbeing redeemed, or as part of an external service to one or moreoperating environments.

In a particular embodiment, the system further comprises at least oneoperating context corresponding to one or more right(s) expressed by atitle. The operating context is configured to describe and/or providecomponents of an operating environment that is effective to process theright(s). The operating context may define or reference a specific TPE,or may provide a specification for a TPE that is created “on-demand” toprocess one or more rights.

Additional embodiments include those in which the title includes atleast one right that is associated with the operating context.Alternative additional embodiments include those for which the titleincludes at least one operating context that is associated with at leastone right. If a plurality of operating contexts are provided, the titleresolver component in the operating environment is responsible fordetermining the effective operating context to use in processing eachredeemed right.

Furthermore, each operating context, whether expressed as part of anoperating environment or by a title, may be provided in a plurality ofways. In a first embodiment, the operating context may be “embedded,” inwhich case, the operating context is present within the operatingenvironment or title. In a second embodiment, an operating context maybe “named” by the operating environment or title using a name ordescription suitable for the purpose. For example, a name might be aglobally unique ID, a textual name, or a combination of a plurality ofelements such as a textual name and a version number. A named operatingcontext may be located and made available to the operating environmentby use of a directory service, a name service, a database, or equivalentservice in the operating environment such as a service router. Inparticular, an operating context may be obtained from a service resolverand registry to which it has been published. Alternatively, an operatingcontext may be referenced from an operating environment or a title usingany supported referencing technology. Some well known technologiesinclude an XPointer and a URI. If a plurality of operating contexts areexpressed within a title, each operating context may be expressed usinga similar or different means. The provisions of such operating contextscan be provided by those having ordinary skill in the art using thisdisclosure.

An operating context is a data structure that specifies one or moreaspects of an operating environment. FIG. 5 illustrates an example of arepresentation of an operating context. Each operating context may berepresented in any common format used for representing information. Onesuch representation is an XML data structure such as is commonly used bythose skilled in the art. Other representations, such as ASN.1, databasetables, tag-value pairs, etc. may also be used without loss ofgenerality.

Each operating context (5000) comprises zero or more instances of itscomponent elements, each of which may be named, referenced, or includedby embedding within the operating context. These component elementsinclude an optional name or ID (5005), additional operating contexts(5010), user interface component specifications (5020), operatingenvironment components (5030), and processing workflow specifications(5040). Each element reference may be accompanied by security indiciathat may be used to verify its integrity (5011, 5021, 5031, 5041).Optional security indicia (5050) may be included for the operatingcontext itself to permit the verification of the operating contextitself.

An optional name or unique identifier may be included within eachoperating context in order to make the operating context uniquelyidentified. A preferred identification mechanism is to use a globallyunique identifier such as a Microsoft GUID or a UUID as specified byDCE. Alternatively, a textual name may also be used, either inconjunction with the unique ID, or on a stand-alone basis.

Zero or more additional operating context specification(s) (5010) may beincluded within an operating context. In some embodiments, theseadditional operating context specifications are embedded within thefirst operating context. In other embodiments, the additional operatingcontext specifications may be named by the first operating contextinstead of being embedded within it. Alternatively, the additionaloperating context specifications may be named by the first operatingcontext using any of the common referencing schemes mentioned herein. Ifa plurality of additional operating context specifications are includedwithin a first operating context, each may use the same or differentmethod selected from embedding, naming, or referencing. Each additionaloperating context specification included within an operating context maybe accompanied by security indicia (e.g. 5041) useful in determining itsauthenticity and integrity.

Zero or more user interface component specifications (5020) may beincluded within an operating context. In some embodiments, these userinterface component specifications are embedded within the firstoperating context. In other embodiments, the user interface componentspecifications may be named by the first operating context instead ofbeing embedded within it. Alternatively, the user interface componentspecifications may be named by the first operating context using any ofthe common referencing schemes mentioned herein. If a plurality of userinterface component specifications is included within a first operatingcontext, each may use the same or different method selected fromembedding, naming, or referencing. Each user interface componentspecification included within an operating context may be accompanied bysecurity indicia (e.g. 5021) useful in determining its authenticity andintegrity.

Zero or more operating environment components (5030) may be includedwithin an operating context. In some embodiments, these operatingenvironment components are embedded within the first operating context.In other embodiments, the operating environment components may be namedby the first operating context instead of being embedded within it.Alternatively, the operating environment components may be named by thefirst operating context using any of the common referencing schemesmentioned herein. If a plurality of operating environment components isincluded within a first operating context, each may use the same ordifferent method selected from embedding, naming, or referencing. Eachoperating environment component included within an operating context maybe accompanied by security indicia (e.g. 5031) useful in determining itsauthenticity and integrity.

Zero or more processing workflow specifications (5040) may be includedwithin an operating context. In some embodiments, these processingworkflow specifications are embedded within the first operating context.In other embodiments, the processing workflow specifications may benamed by the first operating context instead of being embedded withinit. Alternatively, the processing workflow specifications may be namedby the first operating context using any of the common referencingschemes mentioned herein. If a plurality of processing workflowspecifications is included within a first operating context, each mayuse the same or different method selected from embedding, naming, orreferencing. Each processing workflow specification included within anoperating context may be accompanied by security indicia (e.g. 5041)useful in determining its authenticity and integrity.

Optional security indicia (5050) may be included for the operatingcontext itself to permit the verification of the authenticity andintegrity of the operating context itself. Security indicia in anoperating context may be any indicia that may be used to verify theintegrity of the referenced component, e.g., a checksum, digital hash,or digital signature.

An operating environment constructed in accordance with an operatingcontext as described above is said to be “defined”. Operatingenvironments may be check-summed or digitally signed using well knownmethods, and these security indicia may be checked when an operatingenvironment is assembled. If the environment is assembled without theuse of an operating context, but the security indicia associated withthe operating components are checked to assure their integrity, theoperating environment is said to be “assured”. In some embodiments, thesecurity indicia of one or more operating contexts may be used to verifyeach component as the operating environment is provided to ensure thatthe operating environment provided has not been tampered with orotherwise corrupted. Operating environments that are defined using anoperating context and are constructed using the security indicia of anoperating context to verify their integrity are said to be“defined+assured”.

In more specific embodiments, any one of the operating contextsdescribed above is combined with any one of the operating environmentsjust described, i.e., one of each operating context (embedded, named,and referenced) is combined with one of each operating environment(assured, defined, and assured and defined) to provide an embodiment ofthe present invention for each of the 3×3=9 different combinations. Instill more specific embodiments, the operating environment is bothassured and defined by an operating context. Again, the provision ofsuch operating environments can be accomplished by those having ordinaryskill in the art using this disclosure.

Each operating environment may be statically configured, in which theconfiguration of the components is not changed using an operatingcontext. This implementation model is straightforward and provides titleprocessing within fixed operational constraints. Some business modelsrequire different configurations, and these configurations may beaccommodated using a plurality of operating environments, eachstatically configured in a different manner. As is clear to the reader,this deployment model scales poorly. A second deployment option is touse operating environments that are dynamically configured using anoperating context. In this model, the operating components are allinstantiated, but are only referenced and used on an as needed basis.This model, while more flexible, also scales poorly across a pluralityof devices and device types. Dynamic configuration often requires apriori knowledge of workloads and system performance dynamics that areoften not precomputable. Similarly, dynamic configuration mechanismsintroduce issues of component distribution and whether all neededcomponents are available at the time they are needed. A thirdalternative, the dynamic loading and unloading of components based uponan operating context is also provided. In this alternative model,operating environment components need not be instantiated until they areactually needed by a specific operating environment. Each operatingenvironment may be constructed using components which are not runningprior to the creation of the operating environment, which areinstantiated as they are needed, and are unloaded as soon as they areused. When coupled with the ability of an operating context to embed oneor more components, this provides for a portable, assured, and definedsystem for the processing of titles. This technology thus permits thedigital bearer nature of titles to be fully expressed to the point thatthey can be processed immediately by a bearer. Again, the provision ofsuch operating environments can be accomplished by those having ordinaryskill in the art using this disclosure.

According to specific embodiments, the present invention providesmethods for processing digital bearer instruments and computer-readableprogram code devices that are configured to implement such methods(i.e., software). The context is configured to provide an operatingenvironment effective to process at least one right, and is furtherselected from the group consisting of: embedded, named, and referencedoperating contexts; and said operating environment being selected fromthe group consisting of: assured, defined, and assured+defined operatingenvironments.

6.4.2.1.1.1 Task Map

As described herein, each operating environment supports the capabilityto dynamically reference, locate, and instantiate applicationcomponents. In some embodiments, processing an operating contextspecification causes an operating environment to load or cause to beloaded the identified required components, including applicationcomponents, built-in components, and external services, and userinterface components including screen, panes, fonts, skins, and relateduser interface components. Component specifications may be definedwithin the operating context specification, or alternatively, theoperating context specification may specify one or more task maps thatperform the specification of one or more desired components. Anoperating context specification may also define distributed workflowparameters, and associate specific components with portions of theworkflow. The operating environment implements the desired securitymodel and session handling, including session isolation in accordancewith a specification provided within an operating context.

In some embodiments, a task map is used within an operational context toprovide a map between specific distributed workflow operations andspecific services or application components (either plug-in orbuilt-in). For example, a task map may identify the shopping cartapplication component to be used in a specific implementation, and mayfurther identify the application components, layouts, and styles to beused when working with this component.

A task map may include one or the following elements:

-   -   a. Property/attributes    -   b. Identification    -   c. View identification    -   d. Package identification    -   e. Task name    -   f. View specification.    -   g. Optional localization/internationalization specification,    -   h. Application specifications    -   i. Application component specifications    -   j. Task definitions    -   k. Default package path    -   l. Error handling

A task map identifier may comprise a unique ID or name, consistent withother unique ID and name descriptions within the Active User interfacearchitecture.

A task map may comprise one or more task specifications. Each taskspecification may include optional specifications for task names, viewspecifications, package specifications, skin specifications, style sheetspecifications, and locale specifications. A task name provides adescriptive name for the task, such as “Accountless checkout.” A taskmay be associated with a specific title expressed right action, a groupof title expressed right actions, or an entire operating context.

A view specification provides a specification for the look and feel forthe task and may be provided, for example, in the form of an XMLspecification as described above. The view specification may beidentified with a view identification. A view identification maycomprise a unique ID or name, consistent with other unique ID and namedescriptions within the User interface architecture.

A package identification may comprise a unique ID or name, consistentwith other unique ID and name descriptions within the User interfacearchitecture.

An optional localization/internationalization specification specifiesthe localization parameters to be used for this task. This specificationmay be expressly specified, or may reference a style sheetspecification. In embodiments where thelocalization/internationalization specification is provided, there areseveral mechanisms available. In one embodiment, the application mayfollow ISO conventions for specifying various sets of localizationparameters. For example, the language code may use the ISO default for“US English”.

An application component specification specifies names or describes auser interface component (either built-in, plug-in, or external service)that provides application services for this task. User interfacecomponent references may take the forms described herein, or may takeother forms appropriate to the implementation system or platform. Invarious embodiments, the application component specification may be aDLL or COM object, a Java class, an application operating context suchas a JAR, a CORBA object ID, a service identifier or specification, orother implementation dependant method of identifying the specificapplication component desired. Optionally, the application componentspecification may specify the calling and response interface for theapplication component. In some embodiments, the application componentspecification comprises a reference to an external service enabled forthe processing of title-based rights.

The task class specifications may define alternate applicationcomponents or methods of specific application components that should beassociated with specific distributed workflow components. For example,the task class specification may define a specific “Thank You” screenfor the “Accountless checkout” task. It defines a specific applicationcomponent, view, and other presentation information with a specific“Thank You Screen” as a distributed workflow event within the taskmanager. Upon receipt of the “Thank You Screen” distributed workflowevent, the User interface causes the application component to beexecuted within the specified operating context.

A title (or other application component may, indirectly through itsview) may specify an operating context it requires in order to provide atitle expressed right processing environment. If the User interface,operating on behalf of the title is unable to locate and successfullyload a specified operating context, component, or remote service, theerror handler UI is invoked in accordance with the current error handlerUI specification. The error handler used is the error handler associatedwith the current operating context, or if an error handler is notspecified for the current operating context, the error handler of aparent task map or operating context, or the error handle for thedefault operating context is used (if defined).

In one example embodiment, a user has rights to both child and adultcontent. If the user is operating within a branded (for adult content)title expressed right processing environment, the operating contextspecification for a piece of child content may require a change incontext to a different operating context (either within the same titleexpressed right processing environment, in a different title expressedright processing environment, or in an operating context) beforepermitting the user interaction to continue.

An example task map is provided below:

<Taskmap> <CarrierBilling_Confirm view=“[TaskPath]Cart/CarrierBilling/CarrierBilling_Confirm.xml” confirm=“[TaskPath]Cart/CarrierBilling/CarrierBilling_Confirm.xml” gsmNumber=“[TaskPath]Cart/CarrierBilling/CarrierBilling_gsmNumber.xml” thankyou_actless=“[TaskPath]Cart/CarrierBilling/CarrierBilling_ThankYou _actless.xml” thankyou=“[TaskPath]Cart/CarrierBilling/CarrierBilling_ThankYou.xml” package=“[TaskPath]Cart/Cart.swf” actless=“[TaskPath]Cart/CarrierBilling/CamerBilling_Confirm_actless.x ml” sprint_actless=“[TaskPath]Cart/CarrierBilling/CarrierBilling_Confirm_ac tless_sprint.xml” sprint=“[TaskPath]Cart/CarrierBilling/CarrierBilling_Confirm_sprint.xml ” /> - <! - - Mobile Input - - > <Input_Mobile package=“[TaskPath]Cart/Cart.swf” /> <GsmNumber view=“[TaskPath]Cart/CarrierBilling/CarrierBilling_gsmNumber.xml” package=“[TaskPath]Cart/Cart.swf” /> <PhoneSelector package=“[TaskPath]Cart/cart.swf ” view=“[TaskPath]Cart/PhoneSelector.xml” /> <MyStuff view=“[TaskPath]/MyStuff/MyStuff.xml”  package=“[TaskPath]roots.swf” /><QuickFlow  package=“[TaskPath]QuickFlow/QuickFlow.swf” /><WalletCreditCardAddress view=“[TaskPath]Wallet/WalletCreditCardAddress.xml” package=“[TaskPath]Wallet/wallet.swf” locals=“[TaskPath]Wallet/AccountDetail” /> <WalletCreditCard view=“[TaskPath]Wallet/CreditCard.xml” package=“[TaskPath]Wallet/wallet.swf’ locals=“[TaskPath]Wallet/CreditCard” /> <WalletDelete_Confirm view=“[TaskPath]Wallet/Delete_Confirm.xml” package=“[TaskPath]Wallet/wallet.swf” locals=“[TaskPath]Wallet/Delete_Confirm” /> <WalletCash view=“[TaskPath]Wallet/Cash-xml”  package=“[TaskPath]Wallet/wallet.swf” locals=“[TaskPath]Wallet/Cash” /> <WalletAddCash view=“[TaskPath]Wallet/AddCash.xml” package=“[TaskPath]Wallet/wallet.swf” locals=“[TaskPath]Wallet/AddCash” /> </Taskmap>

6.4.2.1.2 Service Manager/Controller

According to various embodiments, a title processing system implementsone or more components called a Controller and/or Service Manager. Insome embodiments, the functions of a Service Manager and Controller maybe implemented as a stand-alone service, as part of another component,as a loadable component, or as an external service. In some embodiments,a Service Manager and Controller may be implemented as separatecomponents. Alternatively, they may be combined as a single component. AService Manager and Controller is part of a TPE that manages the TPE'scomponents and provides the interface and “glue” logic between atvarious title-enabled services. These interface and glue logic servicesmay include parameter marshalling, ensuring specific services are loadedand running, and the like.

The service manager's functionality may be implemented as part of theTPE itself, or may be implemented as a plug-in, or as an externalservice within a TPE. A service manager supports, in conjunction withother components such as a context, application, and component loader(described below), the demand loading and unloading of components,including any verification and validation requirements. The servicemanager defines and controls the operation of the context, application,and component loader in accordance with defined method of managingservices and components for a TPE. In some embodiments, the servicemanager functionality is contained within other TPE components.Optionally, a service manager coordinates with an underlying operatingsystem component to ensure these functions are performed as required toenable a TPE.

A Controller interacts with other services, such as those describedbelow, to facilitate the user and service interactions to implement thespecified interface and service calls necessary for the specifiedexecution within a TPE.

In more specific embodiments, a Controller is used to control flows,views, validation, and similar interface functions. In some embodiments,the controller component is used to transform data flows from one formatto another so they may be used within an existing specification. Part ofthe Controller specification may define views, languages, and protocolsfor communicating between user interfaces and service components andbetween service components on behalf of a user interface. A viewspecification defines, in part, the layout, styles, user interfacecomponents, and the like to be used when displaying the output from aTPE, operating context, or external service. For example, when an outputof one service is received, the controller may transform or change theformat of the output to better fit within the display pane of a userinterface to which it is mapped. Part of the definition may include a“form” definition, that optionally specifies how the elements of the“form” may be validated. In a first embodiment, a user interfacecomponent may perform direct validation of entry fields using the formspecification rather than rely on the Controller or other services forvalidation. In some embodiments, a Controller specifies how the form andthe form elements can be validated, for example, using a regularexpression (e.g. regex) or indication of a remote service to be used(such as phone number validation, location validation, etc.). Thiscapability provides improved response times to the user and offlineoperation capabilities. This can be accomplished using methods known tothose having skill in the art.

In other embodiments, a Service Manager and Controller specifies,collects from the user or other location in the system, or otherwisemanages the authentication and authorization information to be used whenaccessing specific services or components within a TPE. This can beaccomplished using methods known to those having skill in the art.

6.4.2.1.3 Context, Application, and Component Loader

According to some embodiments, a context, application and componentloader provides context, application and component loading services,including downloading services to retrieve remotely stored applicationcomponents, validation and verification services that ensure a componenthas not been tampered with and is authorized to execute. Optionally, acontext, application and component loader provides task managementservices to control and/or coordinate the execution of runningcomponents and applications components.

In some embodiments, each instance of a TPE may cause the demand-loadand unload of portions of its contexts, applications, components andconfigurations on an as-needed basis. In other embodiments, an operatingcontext loader component instantiates a complete TPE on the basis of aoperating context specification, as outlined herein.

In some instances, portions of the TPE and of other architectures thatthe TPE relies upon, may be distributed to alternate systems or devices.Similarly, service requests may be mediated by a service router orservice resolver and registry and directed to a local instance of aservice provider, may be passed to a remote service instance, or acombination of both approaches may be performed. For example, a TPE mayrely on an internal identity management component, may distribute theidentity management component to another system, or may use acombination of both methods. Such TPEs can be provided using thetechniques described herein and methods known to those having skill inthe art.

In order to ensure the proper functioning of the processing environment,a TPE may perform validation and verification of demand-loaded and/ordistributed components. Demand-loaded components are also referred toherein as plug-ins. In some cases, the validation and verification maybe performed by the application loader itself using well-knowncryptographic means such as crypto-hashes such as those generated byMD5,a checksum or CRC, or by using methods such as self-validatingpackaging such as Microsoft's CAB or Java's signed JAR files. Inalternate embodiments, TPE components may be validated using SAMLassertion(s) in accordance with SAML specifications. Such TPEimplementations can be provided using the techniques described hereinand methods known to those having skill in the art.

In other embodiments, the validation and verification functions may beperformed by underlying operating system functions. For example, thevalidation and verification of signed applications is provided by theunderlying task loader in the Windows XP and Windows CE operatingsystems, and in the Java runtime environment. The processing environmentmay be configured to rely on these services when executing upon theseoperating systems that provide this functionality.

6.4.2.1.4 Communications Manager

In some embodiments, a communications manager component of the TPEmanages the communications between TPE components. This component issometimes called a connection manager. Different communications managersmay be provided to support different protocols, for example, a TPE maysimultaneously support a first communications manager that supports theSOAP protocol, a second communications manager that supports an RPC overHTTP protocol, and yet a third communications manager that supportsSHTTP. Each aspect of a communications manager is preferably implementedas discrete components, but may be implemented as one or more componentsin some implementations. The communications management componentoptionally includes the capability to orchestrate the completion of oneor more services on behalf of the TPE.

Communications manager components may also utilize directory services bycalling a Service Resolver and Registry component to resolve servicelocations and interface specifications.

In yet other embodiments, a communications manager component implementscommunications between the User interface and one or more TPE services.In some embodiments, the communications manager provides SOAPformatting, transmission, and retransmission services between the Userinterface and one or more services. Alternatively, a communicationsmanager may provide XML-RPC, CORBA, or other remote procedure callservices to a TPE. In some embodiments, a communications manager mayprovide more than one type of RPC service, and may either select the RPCformat to use when communicating with a specific service, or translatebetween RPC formats in order to facilitate communications betweenservices. These services may be provided on the same device as thecommunications manager, or may be provided on a different device.

In one embodiment, the communications manager component maintainsconnectivity and state for connections. An instance of a communicationsmanager may communicate with more than one service at a time.Specifically, a communications manager may simultaneously manage thecommunication with multiple components, services, and TPEs, includingmaintaining simultaneous communication with similar or differentversions of services hosted on different servers.

6.4.2.1.5 Identity Provider

In some cases, a TPE provides, or causes to be provided, an identitymanagement service, sometimes called an identify provider. The identitymanagement service may be implemented as part of the TPE itself, or maybe implemented as a plug-in, or as an external service. An identitymanagement service provides methods for validating components of the TPEarchitecture to ensure that they have not been tampered with and thattheir use is authorized within a specific instance of a title expressedright processing environment. Such TPE functions can be provided usingthe techniques described herein and methods known to those having skillin the art, and may include such methods as PKI, multi-partyauthentication, and related components. The identity management servicesmay also used to validate and establish the identity of specific usersof one or more TPEs.

The Identity Provider can comprise a title-based Identity Provider or anexternal third party Identity Provider service. A plurality of identityproviders services may be supported within an instance of a TPE. TheIdentity Provider can be required as part of the particularimplementation if a Service Router needs to authenticate itself to theIdentity Provider and include a SAML Artifact in messages to theendpoints (where specified by the service definition).

In some embodiments, a local instance of an identity managementcomponent is also provided. It is useful to have a local identitymanagement component as part of the User interface for deployments wherethe User interface is not able to maintain regular communication with anexternal identity verification and authentication service. The identitymanagement component that may be embedded within a TPE, such as providedby an AV (or provided as another component) is typically used tovalidate components and operating context specifications. In one exampleembodiment, such an identity management component would cache andvalidate SAML assertions related to the validity of well definedcomponents and specifications. The SAML assertions would be pre-storedin the cache for use when the TPE is not able to make an onlineconnection to an identity verification source. The local instance of theidentity management component may also be used to validate an initial ordefault operating context specification during TPE startup.

6.4.2.1.6 Title Resolver

According to a set of embodiments exemplified in FIG. 6, a titleresolver (6100) provides title resolution services to a TPE (e.g. 4140of FIG. 4). A title resolver comprises a state server (6120), one ormore authentication providers (6130), optional CODEC modules (6140a/b/c), optional interfaces to content providing services (6150 a/b/c),one or more interfaces to service resolvers and registries (6170),optional interfaces to external identity providers (6160), and otherexternal service interfaces (6180 a/b/c).

A Title Resolver module 6100 performs the task of resolving all titlematerials presented. In some embodiments, a title resolver may be usedto resolve a reference to a specific title or right. In other cases, atitle resolver is used to expand incomplete title materials using cachesor stored copies of common, well known title materials. The use of atitle resolver to expand title materials presented to it enables thereuse of common title materials. This reduces the size of individualtitles at the expense of having to include those referenced materials atuse time. In some embodiments, these common materials are calledtemplates. In other embodiments, they are managed as items to beincluded at resolution time. One example of this technique is theexpansion of title materials to include specific content from a contentstore upon presentation of a title. Other examples include expanding atitle to include common definitions for classes of rights. This permitsthe use of an “included by reference” capability in titles, which inturn supports the substantive reduction of the size of title objects.

FIG. 7 is a flowchart which illustrates an example of a process forresolving title materials.

In step 7110, a title resolver verifies the integrity of any providedtitle materials. This ensures that all title materials provided have notbe tampered with, damaged, or are unintentionally incomplete.

In step 7120, a title resolver identifies, locates, and obtains copiesof any referenced title materials (recursive). In each of these cases,if a title material is referenced using a unique ID, the title resolvermay recognize the unique ID and use that unique ID to look up the titlematerial using a database of title materials, a directory service, atitle manager, or a service registry. This may be recursively repeateduntil there are no title materials or content left to identify, locate,or obtain.

In step 7130, a title resolver validates all title materials to ensureauthenticity and validity.

In step 7140, a title resolver validates aspects of operating contextsand the title materials, to ensure that provided title materials arevalid for operating within the specified operating context. A titleresolver further checks to see if there are conflicts or ambiguities inthe specifications within an operating context or within a titlestructure, the Title Resolver is responsible for resolving the conflictsor ambiguities in a manner that permits the processing of the title tocontinue.

In step 7150, a title resolver ensures or authenticates ownership of thetitle.

In step 7160, a title resolver effects the decoding and decrypting anytitle elements that are encoded or encrypted.

In step 7170, a title resolver effects the retrieving of any content orresource(s) requested by a title.

In alternate embodiments, a Title Resolver may be responsible forexecuting and acting upon rules and triggers that are applicable to thetitle materials presented. In various embodiments, the functions of aTitle Resolver may be implemented as a separate service, either as aloadable component, as an external service, or combined with otherservices and components.

An additional function of the Title Resolver may be to refresh oldtitles. For example, if information contained within a title becameoutdated, this information could be automatically refreshed either byreplacing the title completely or by adding a new stub object thatupdates the information. A Title Resolver may invoke additionalprocesses as required to process and update title materials (6110) suchas the CODEC module (6140 a/b/c) , a state server module (6120) , acontent interface module (6150 a/b/c), an authentication provider(6130), a service resolver and registry (6170), an identity provider(6160), or other external service (6180 a/b/c) as required.

A state server module (6120) maintains and verifies state associatedwith the use of titles throughout the ecosystem. The state server maywork in conjunction with the Title Resolver in order to verify thevalidity of the title and may generate new stub objects associated withthe title on every redemption and exchange. The state server may be ahigh-capacity, high-availability, and high-performance system that canbe widely distributed and chained in order to perform fast validationfor titles in use. The state server may perform functions and algorithmsassociated with the chained hash, one-time password, and key-splittingtechniques.

A content interface module (6150 a/b/c) performs the tasks associatedwith retrieving specified content from a particular content store. Thismodule may generally be invoked by a Title Resolver to resolve areference to external content. The content interface module may beextensible to support a variety of content and resource systems in useby content publishers.

A CODEC module(6140 a/b/c) performs coding and decoding functions on thecontent retrieved by the Title Resolver. The primary purpose of thismodule is to encapsulate content in a secure package as determined bythe security required of the title and established by the rules. Forexample, this module can perform digital watermarking of music and imagecontent, and it can also be used to encrypt the content in a traditionaldigital rights management package. Additionally, the CODEC can be usedby the Title Resolver to decode contents within the title beforeprocessing by the Title Resolver. The CODEC may provide mechanisms tosupport these functions as required within the ecosystem.

As described in U.S. patent application Ser. No. 11/741,952 filed Apr.30, 2007, now U.S. Pat. No. 9,621,372, issued Apr. 11, 2017 (AttorneyDocket No. API1P008A), the entire disclosure of which is incorporatedherein by reference for all purposes, titles can be validated using atitle resolver and/or a state server, both of which are components of atitle management system. FIG. 8A is a flow chart depicting an example ofsuch a title validation process. The title is submitted by a client to atitle resolver service for authentication (8110). The title resolverservice examines the title's digital signature (8120). If the digitalsignature is incorrect, the title resolver service rejects the title andthe title validation process terminates with an “invalid title” result.If the digital signature is correct (8130), the title resolver serviceforwards the title to the state server process for further validation(8140) of the state value in the title's stub. The state server processuses the state value or other indicia that are part of the title (8150),computes a value from these item(s), and compares it against a valuestored in a database (8160). If the two values match (8170), the titleis validated by the state server (8180). A “title valid” response isreturned to the title resolver service (8190), which in turn returns a“title valid” response the client (8200). If the state server cannotvalidate the title, it returns a “title invalid” response and thevalidation process terminates. The above example is one method ofvalidating titles; additional methods of validating title materialsinclude digital signatures, comparison of transaction indicia totransaction databases, and other methods well known to those skilled inthe art.

As described in U.S. Patent Publication US 2006-0036548 A1 (AttorneyDocket No. API1P004X4), the entire disclosure of which is incorporatedherein by reference for all purposes, titles can be validated using atitle resolver and/or a state server, both of which are components of atitle management system. FIG. 8B is a flowchart depicting an alternativetitle validation process. In one embodiment, the consumer device is usedto communicate the redemption request to the title manager (8210). Thetitle manager performs title processing (8215) and returns a titlecommand to the consumer device (8220) redirecting the consumer to thecontent. The consumer device communicates the title directly to thecontent proxy (8225), which subsequently makes a request to a trustedtitle resolver (8230) in order to validate and authenticate the title.In this embodiment, the title resolver is a separate component. Inanother embodiment, the resolver functionality may be incorporateddirectly into the content proxy.

The title resolver both validates the title (by ensuring that rules areproperly executed) and also authenticates the title. In one embodiment,in order to properly authenticate the title, the title resolvercommunicates the title object to the state server (8240). The stateserver subsequently authenticates the title object (8245) using anauthentication technique specified by the title and supported by stateserver . The authentication process (8250) may further involve securityindicia included with the title object. The endorsement process isresponsible for placing the security indicia in the title object (8260).In one embodiment, the state server returns the authentication responseto the title resolver along with updated security indicia for the title(8270). If the title is authentic and valid, the title resolvercommunicates the updated security indicia to the title manager andresponds to the original request by content proxy (8280).

Upon successful authentication, content proxy permits the requestthrough to content which is then returned to consumer device (8290). Ifthe transaction should substantially fail, and consumer device cannotcommunicate with content, an error message may be returned. In oneembodiment, the error message is substantially communicated to allparticipating parties to ensure an orderly rollback of the transaction,if needed

6.4.2.1.7 Service Resolver and Registry

The Service Resolver and Registry is intended to be a general businessand service registry that can be used by all title enabled components tolookup essential business and service definitions, title materials, andworkflows. One or more service resolvers and registries may beconfigured within a TPE configuration. Each Service Resolver andRegistry component may be used to support one or more Service Routersand other title enabled applications, and provides a common locationfrom which all requests for contexts, applications, title materials, andrelated services may be resolved. A Service Resolver and Registryfurther provides services to a TPE, TPE applications, and othertitle-enabled systems to assist in resolving one or more servicesreferenced from title materials or processing workflows. Depending upondesired functionality, the resolver and registry portions of a ServiceResolver and Registry component may be configured as separate modules.Alternatively, they may be configured in conjunction with each other (aspresented herein), or as part of other components.

An authorized user may use a title publisher application to publishservice and alias definitions to a Service Resolver and Registry. Thepublishing process is described below. Alternatively, a Service Resolverand Registry can also be configured using any other means known to thoseskilled in the art. Well known title materials, including templates,well known titles, and related materials also may be published to aService Resolver and Registry in order to make them available to a TPE.In addition, service definitions used by specific rights may bepublished to a Service Resolver and Registry.

A Service Definition stored in the Service Resolver and Registry may bestored as title materials and can include common service specifications,such as those defined using UDDI data structures/elements. In otherembodiments, due to the complexity involved in standard protocols suchas UDDI, a simpler structure may be encapsulated in a title. In stillother embodiments, a Service Resolver and Registry component usesservice lookup techniques, including external service directories suchas those provided by well known mechanisms such as UDDI and LDAP,service registries, and service lookup mechanisms provided bydistributed component systems such as COM/DCOM and CORBA. The ServiceResolver and Registry, in some additional embodiments, can be a servicethat simply accepts an ID for a service and returns a title objectassociated with the ID. The ID is a unique ID for the title object. ForXML representations of a title, this is also called the document ID.

In a first embodiment, a Service Resolver and Registry requires therequesting application to know what record ID is being queried, and willonly support lookups for service definitions (such as used by a ServiceRouter). The Service Resolver and Registry will return the Titlespecified by the record identifier. The returned title contains theservice definition or another service ID, which is the further resolveduntil an actual service definition is obtained. In an alternateembodiment, a Service Resolver and Registry supports lookups forarbitrary titles, including titles that define workflows and relatedtitle processing elements. In yet another alternate embodiment, aService Resolver and Registry provides lookup services to well knowntitle materials, such as templates, contexts, and templated subsets ofrights. In still another alternate embodiment, a Service Resolver andRegistry provides an alias lookup service, by which aliases for wellknown items are resolved to actual entries. Aliases are useful in thatthey permit the renaming of historical title materials and serviceswithout requiring regenerating of all titles that reference the titlematerials or services.

Basic and Advanced search features are available for service lookupsperformed by the Service Resolver and Registry. These features includelookup by ID, and structured queries using well known structured querymechanisms.

A user or application may query the Service Resolver and Registry bysending a message containing the query. A service lookup to the ServiceResolver and Registry returns the service definition. In someembodiments, only Service Definitions are supported and the ServiceResolver and Registry will only allow lookup requests for ServiceDefinitions. In some embodiments, this query is structured as a SOAPrequest. In other embodiments, it may be an LDAP query or a databasequery. An example SOAP message for a Service Resolver and RegistryLookup request is shown below and includes both a LookupType and aRecordId element:

<soap-env:Envelopexmlns:soap-env=“http://schemas.xmlsoap.org/soap/envelope/”><soap-env:Header/> <soap-env:Body> <TtsRequestxmlns=“http://aplaud.com/ns/0.1/tts/protocol”><LookupType>http://daxweb.org/ns/1.0/service</LookupType><RecordId>a080847000001001b3eb63400000091</RecordId> </TtsRequest></soap-env:Body> </soap-env:Envelope>

The LookupType element indicates the type of definition being queriedand can be specified as an XML namespace. Examples of namespacesincludes: http://daxweb.org/ns/1.0/service for services,http://daxweb.org/ns/1.0/service/ota for OTA application definitions,and http://daxweb.org/ns/1.0/service/cdn for content delivery networkdefinitions.

The RecordId element contains a unique identifier for the servicedefinition being queried. This is the Document ID of the correspondingtitle object stored in the service registry.

The response to this example query from the Service Resolver andRegistry is a SOAP message containing a copy of a title object that wasloaded into the Service Resolver and Registry using a title publisher.

6.4.2.1.8 Service Router

According to a set of embodiments, a Service Router provides thefunction of a network-based aggregator and choreographer of servicerequests providing a single point for distributed applications to call.A Service Router simplifies the distributed application services bylimiting the number of services that are available and reachable to aspecific user at any given time. A Service Router can be deployed aspart of a TPE configuration, as a stand-alone component on a network, aspart of a network appliance or device (such as the network devicesdescribed above), or can be shared between multiple TPEs.

A Service Router provides a means by which a specific service, TPE, orTPE client communicates with one or more services. In some embodimentsof the invention, a Service Router functions as more than a dispatch orbroker service. In these embodiments although on the surface a ServiceRouter can appear to have the same traits as other middleware tools, itgoes far beyond these tools and defines the rights-based commerceapproach to routing, coordinating, and integrating services. Therights-based commerce approach to service dispatch applies rights to theinvocation of every service and the manner in which the serviceinvocation is coordinated to form an activity. In these embodiments, aService Router brokers the connections, gateways the connections, andapplies the rules associated with each connection including going to theextent of handling the commerce obligations for each discrete service.In a more specific embodiment of the invention, protocol messages aresent to and from the Service Routers provided herein which in turnbroker the many disparate services used to complete transactions, manageworkflow, satisfy contract requirements, and implement additionalvalue-add.

In another embodiment, a Service Router functions as a proxy service fortitle-enabled services. When operating as a proxy service, a ServiceRouter provides a single point for authentication and authorizationservices associated with titles, as well as providing serviceredirection services. In a first use, a Service Router can isolate theauthentication and authorization steps of ensuring that the title itselfis valid and is provided in accordance with any specified requirements(e.g., on input data, on user credentials) before passing the title toan endpoint service. Alternatively, a Service Router can invoke one ormore rights defined in the title. Further alternative embodiments canhave a Service Router use the title to locate additional informationprovided externally from the user or the title itself, and use the titlein conjunction with that additional information to invoke the networkservice or application desired.

Also when used as a proxy service, a Service Router is advantageous toblocking forged or otherwise invalid titles and for eliminatingnon-authenticated traffic from a network service. In this manner, aService Router can act as a title-enabled firewall. When coupled withthe network device capabilities described above, a title-enabledfirewall network device can be constructed that limits the networktraffic that crosses the firewall to authorized and authenticatednetwork traffic.

In an alternative use as a proxy, a Service Router can redirect specificnetwork service calls presented to it to a different network service. Inthis example use, a Service Router can redirect a service request fromto an alternate service host on the basis of a table lookup, directoryservice lookup, a load balancing algorithm, or other network service. AService Router accepts the service request, looks up the service requestin a local or remote table, in a directory service, uses the result ofan output of an alternative network service such as runtime, or appliesa load-balancing algorithm to determine the network destination of theservice. Alternatively, a Service Router can invoke one or more rightsspecified in a title to determine the routing of a specific servicerequest.

In some embodiments, Service Routers are interconnect gateways thatunderstand and apply rights-based commerce rules. Coordination of thevarious services is a flexible and powerful feature of a Service Routerand is advantageous in that it is a simpler approach to Web servicescoordination than incorporating a full-fledged BPEL4WS engine (andgrammar).

A Service Router provides a mechanism by which external third partyservices can easily and securely participate in a rights-based commercenetwork. In some embodiments, a Service Router provides atitle-enablement front end to non-service enabled network applicationsand services. In this example user, a Service Router authorizes andauthenticates the title-based request and calls a network-based serviceor application described in association with one or more rights definedin the title without passing the title to this service. An example ofthis type of use was given above in association with the ruptime call,in which an external service is called by the Service Router during theprocessing of a service request. Alternatively, a Service Router can usethe title to access a profile that contains authentication materials tobe used in conjunction with network services and devices.

In other embodiments, a Service Router is a generic handler forformatting and routing service requests to and from service endpoints.In some embodiments, a Service Router preferably sends synchronous Webservice requests to service endpoints. The use of Web-based protocols ismerely an example, and the protocol used can change as required on animplementation-required basis. In some embodiments, the SOAP over HTTPprotocol is supported by a Service Router. Other protocols can beimplemented by those skilled in the art.

In some embodiments, a plurality of Service Routers can operate together(e.g. clustered) to form a “virtual” service, in which any of thecooperating Service Routers can accept a message and process it. Inother embodiments, Service Routers can be operated in “proxy” mode toinspect and then route each message to a subsidiary Service Router.

In still other example embodiments, a Service Router functions as anabstraction layer between a TPE and external Web services; and theService Router serves as a coordinator for the services. In an exampleof such an embodiment, a Service Router is a simple abstraction layerthat defines the interaction with TPE components and establishes abaseline for services, service descriptions, and service adapters. Otherembodiments model service contracts described in titles, and provideenhanced services such as coordination. An embodiment used depends uponthe implementation requirements.

In these embodiments, a request received by a Service Router can bedirected to a plurality of network services or network applications,either in serial, parallel, or in combination, and the result of one ormore of these requests is used to formulate the request to therequestor. Service Routers also can be implemented inline to thetraffic, as service endpoints, or as filters. In some embodiments of theinvention, a Service Router can process message traffic inline byintercepting or proxying message traffic. In these embodiments, aService Router receives a message, inspects its content, optionallyprocesses the message in accordance with one or more specifications, andthen optionally forwards the message to the same or different recipient.In one embodiment, a Service Router can implement a workflow thatintercepts message traffic from a cell phone, inspect the content forthe presence of rights managed content, replace said rights-managedcontent with a title-based offer for the rights-managed content, andforward the altered message to its intended recipient. Readers skilledin the art understand how a Service Router operating in this manner isvaluable to limit the distribution of rights-managed content withoutlocking the content to specific devices.

A Service Router can take many forms that include embedding in networkswitches, routers, gateways, and firewalls. Each of the embodiments oftitle enabled network devices described above can be implemented usinginline code, or they can be implemented using a Service Router embeddedwithin a network device.

A component schematic and Service Router interactions in accordance withone embodiment of the invention are depicted in FIG. 9. In this figure,the DCE component (9010) refers to any extant TPE, or a DCE, TTS, or AVcomponent that can invoke a service call that can be fulfilled by aService Router. These components can include DCE components such asLockbox and Title Manager services, an AV Viewer, or any TPE that caninteract with either a DCE or AV environment. Example external servicesare presented by the top set of boxes, labeled OTA service (9020), DRMservice (9030), and Other Service (9040). These external services aredestination services for requests processed by the Service Router (9100)and its components. Other services may also be referenced by a ServiceRouter, including, for example, specific adapters, identity, titletransaction, title managers, TTS, DCE, TPE, and the like.

6.4.2.1.8.1 Authentication and Authorization of the Service Router

Some embodiments described below assume that the Service Router has beenvalidated and is authorized to provide the service routing function.Service router authentication and authorization is orthogonal to thefunctionality of the Service Router itself. The authentication andauthorization steps described below apply equally to all implementationsof a Service Router, and the authentication and authorization stepslisted below can be performed by the Service Router before commencingoperation, at any step of the example flow processes described herein,or can be performed during provisioning of a Service Router andpreconfigured into the Service Router configuration.

In some embodiments, the Service Router verifies its own identity andauthorizations with an identity provider by authenticating to theidentity provider and obtaining proof of identity and optionallyauthorizations from that identity provider. The step of authenticatingthe Service Router can be performed in-line with the transaction whenneeded, or it can be performed as a precursor operation before theService Router begins processing requests. An example of this type ofauthentication, performed in-line with the transaction as a precursor toprocessing the transaction, is shown in FIG. 10 as “2: Authenticate”.The authentication and authorization mechanism can be performed at anystep for which an authorization or authentication can be required.Alternatively, the authentication and authorization steps can beperformed as a precursor to processing a transaction. In otherembodiments, the authentication can be performed, at least in part,using cryptographic means, such as a cryptographic hash such as MD5, adigital signature, public/private key pair, digital certificate, orother means well known to those skilled in the art. Particularly, insome embodiments, a cryptographic hash or digital signature is used tovalidate the Service Router executable as part of the authorization andauthentication process. In other embodiments, a challenge/responsemechanism can be used.

In some embodiments, authorization and authentication can be providedusing a SAML artifact from the identity provider to the Service Routeritself is provided by the identity provider. In other embodiments, aSAML artifact is provided by the original requestor, and the ServiceRouter can either validate the artifact provided to it or can act as aproxy, with request authorizations and authentications being validatedat the service endpoint. In non-SOAP/SAML embodiments, the requestauthentication is performed using techniques appropriate to theauthentication technique described above. Thus, the Identify Provider isnot required to support SOAP/SAML, but can support other authenticationmethods and techniques in addition to or in place of SOAP/SAML. If aService Router fails to authenticate itself, it can continue processingbut will not be able to invoke any endpoint requiring authentication orauthorization of the Service Router.

6.4.2.1.8.2 Basic Process Flow

A basic process flow for a Service Router component is illustrated inFIG. 10. A client component sends a request (flow 1 of FIG. 10) to aService Router. The client can be part of a TPE, a TPE application suchas a DCE or TTS, AV, another Service Router, or other applicationcomponent making a request to the Service Router. In some embodiments,the request is provided as a SOAP message. In other embodiments,alternate request message encoding can be used without loss ofgenerality.

The request to a Service Router preferably includes authenticationmaterials. In the example SOAP-based implementation, the authenticationmaterials can take the form of a SAML artifact included in a SOAP Headerand are used by the Service Router and/or endpoint to authenticate therequest. Other message encoding and transport mechanisms can encodedigital signatures in the request, or can establish a secure sessionusing a challenge/response mechanism.

The request can specify at least one right to be processed by theService Router. Each right can reference a title, service, or othertitle-enabled process capable of processing the request. If more thanone right is specified, a processing order for rights can also bespecified.

The rights specification parameters, if specified, identify an “action”to be performed by the service endpoint. If no rights specificationparameters are provided, a default action can be identified, eitherexplicitly or implicitly. The request generally contains sufficientinformation about at least one right, at least one Title, and thedesired transaction information (part of request context) to supportvalidation and fulfillment of the request. For example, a purchasetransaction can include payment information suitable for use duringmessage processing of the request at an endpoint. In some embodiments, atf:Title element is sent in the request, in other embodiments, atf:Title element and an authenticator stub is provided as part of therequest.

A Service Router request can comprise the following optional elementseither embodied within, or referenced by, the request message:

-   -   Right—A “right” element indicates to a Service Router the right        being redeemed in a Title. A Service Router will interpret the        contents of the specified right to retrieve the Service Resolver        and Registry-based service identifier.    -   Title—At least one Title object is passed or referenced as the        Title object contains information necessary for the Service        Router to process the request. In XML-based embodiments, this is        referenced as an instance of a tf:Title element.    -   RequestContext—The RequestContext element will contain        additional information, as required, in order to invoke the        endpoint. For example, at the end of a purchase process, the        context in which the title is being redeemed is communicated        with a Service Router. This contextual information is used by        the Adapter to create the desired message(s) required to        complete the transaction(s) at the specified endpoint(s). In        another example, the user might be required to provide        additional information at the point of redemption and this        information is passed as part of the RequestContext. The format        and structure of the RequestContext will vary depending upon the        type of service endpoint the request is being sent to. In some        embodiments, the RequestContext element is omitted as the        context of the request is not relevant or available from other        sources.    -   The Endpoint specification. For example, the request can specify        the endpoint to be used. The endpoint specification can also        specify additional elements to be returned by the endpoint to        identify the request to the originator. For example, these        parameters can be passed to an OTA service that is required to        return them in any response. Examples of these types of elements        can include:    -   TransactionId—A transaction ID used for tracking the transaction        or for support.    -   Message—A user friendly message that is displayed to the user or        included in the Active Voucher.

An example SOAP-XML embodiment of Service Router request fragment isshown below.

<soap-env:Envelopexmlns:soap-env=“http://schemas.xmlsoap.org/soap/envelope/”> <soap-env:Header/>  <soap-env:Body>   <tf:TitleDocument>    <tf:Titleid=“title_id” xmlnsrtf=“http://aplaud.com/ns/0.1/tts/format”>    <![CDATA[... title detail ...]]>    [/tf:Title>    <tf:Stubtype=“protocol”>     <Binding type=“method|”>      <Title/>     <Method/>     </Binding>     <Message>      <![CDATA[... payloaddetail ...]]>     </Message>    </tf:Stub>   </tf:TitleDocument> </soap-env:Body> </soap-env:Envelope>

The diagram provides a sample of a SOAP message that is sent to aService Router. Key points in this example are:

The TitleDocument element is a standard encapsulation of a Title objectand will contain all data to be sent to a Service Router.

The Title continues to be sent to a Service Router and expresses therights as well as the standard meta-data to be used by a Service Router.

The Stub element is new to the protocol but is a standard extensionmechanism employed by Titles. In some embodiments, the Stub is used tocontain the originating message (i.e. payload) sent by the requestingparty.

The Stub uses a Binding element to indicate how it is bound to a Title(or set of Titles). In this example the Stub is bound directly to aTitle and Right.

The Message element contains the payload.

Once a request has been received, there are several optionalverifications that can take place.

The Service Router optionally verifies (flow 2 of FIG. 10) theauthorization materials provided with the request. This verification canoccur in several ways. In a SOAP/SAML embodiment, the Service Routerpasses the SAML artifact provided with the request to an identityprovider for verification. The identity provider can be part of theService Router, or can be separately instanced. The Identity providervalidates the SAML artifact, and either authenticates the request(or),or fails the authentication by sending a failure message. In theSOAP/SAML embodiment, the failure indication can be returned using aSOAP fault message. Alternatively, other messages or messaging protocolscan be used.

In some embodiments, the Identity Provider is acting as the trustauthority for all DCE interactions and can be used to authenticate andauthorize both the service provider and the sending client. Optionally,the service provider can be configured to not verify SAML artifacts.This option permits any component to call a Service Router, even if itsnot part of the DCE trust hierarchy.

There optionally can be an implicit trust established between a ServiceRouter and the DCE components based upon the validity and authenticityof a title passed within a request. This implicit trust model can beimplemented for simplicity when the deployed architecture permits. Anassumption for this implementation decision is that the DCE is operatedin a secure ASP environment (i.e. not federated), and that the IdentityProvider is the trust authority for the transaction based onauthentication (not authorization).

In some embodiments, a Service Router will not require authentication ofthe calling application or its request. This permits backwardscompatibility with older versions of DCE implementations and helpsensure that all DCE components can call a Service Router. A ServiceRouter is, in these embodiments, an unsecured service within the DCE andshould not be exposed outside the firewall. In other embodiments, aService Router can require authentication of the calling applications,using any of the support means known to those skilled in the art.

After the authorization materials are validated by the IdentityProvider, a Service Router examines the redemption right being invoked,obtains the address of one or more Service Resolver and Registrycomponents in which to look up the request, and well as the ServiceIdentifier to be looked for. The service registry can be a ServiceRegistry component, an external registry, part of the Service Router, oranother service that provides services of a registry. In someembodiments, the service resolver and registry address can be definedwithin the Service Router, within the title, or can be defined withinanother service resolver and registry known to the Service Router.

A Service Router preferably uses service definitions stored in theservice resolver and registry. The definitions include identification ofparent and child services, whereby the parent service is described bythe current definition and the child services are described in otherservice definitions. Child services are identified in the parent servicedefinition and is tagged appropriately for processing. In someembodiments, the service definition is defined using a rightspecification embodied in a title. In other embodiments, a servicedefinition in one or more industry standard formats can be used. Forexample, a UDDI registry can serve as a service registry. Alternatively,other directory services such as LDAP or Active Directory can act as aservice registry.

The Service Router then performs a lookup (step 3 of FIG. 10) of theservice identifier in the selected service resolver and registry. Theregistry and service ID provide sufficient information for a ServiceRouter to look up the service definition in the service registry. In oneembodiment, a service definition comprises at least one of:

-   -   A name, ID, and/or description of the destination service        endpoint,    -   A description of the protocol used to communicate with the        service endpoint,    -   A location or identity of a adapter for messages sent to the        service endpoint,    -   A location or identity of a adapter for message received from        the service endpoint,    -   A location or identity of the component used to communicate        between the Service Router and the service endpoint.    -   Parameters to the adapter. In some embodiments, this can take        the form of a WSDL that defines the Web service data types,        messages, operations, ports, and other attributes of the        interface.

In some embodiments, each of the elements included in a servicedefinition can include a URI or URL that describes a protocol, endpointlocation, parameters, and other information required. In otherembodiments, the element definitions can be defined using discretefields. Additional information can be included in the service definitionfor use by different releases of the Service Router. In someembodiments, the service definition can also comprise some securityindicia that can be used to verify the integrity of an adapter orendpoint, for example, a cryptographic hash value or other mechanismsfor authentication and authorization as described above.

It will be appreciated by those having ordinary skill in the art thatthis step of the process provides a layer of abstraction between aService Router and each endpoint implementation. It will be appreciatedfurther by those having ordinary skill in the art that if a serviceendpoint name changes for any reason, then the definition need onlychange in the service resolver and registry and all issued Titles thatuse the changed endpoint can remain unchanged.

Using the service definition, a Service Router then obtains the identityof an adapter to be used in order to structure the request to theendpoint, optionally validates the adapter, and then invokes the adapter(step 4 of FIG. 10). An adapter, if specified, is used to transform theoriginal request to a Service Router into a message in an appropriateformat for use by the specified endpoint. This transform process caninclude data checks, calculations, replacements, configurations, andformatting changes to the original message, and can involve rewritingthe original message to a new format or structure.

In some embodiments, the Service Router obtains information about theadapter from a service resolver and registry. In alternativeembodiments, a Title returned from the service resolver and registry cancontain a reference to the adapter(s) to be used to implement theservice call. In other alternative embodiments, a NULL adapter can bespecified. If security indicia for the adapter are available, theService Router can optionally check the indicia and the adapter toensure the integrity of the adapter. Adapters can be hard coded asstand-alone program executables, as scripts such as in embodiments wherethe protocol used is XML-based, be structured as XSLT stylesheets.SOAP-based embodiments can advantageously use an XSLT-based adapter totransform the message format.

The Service Router can have an independent trust relationship with aservice endpoint, or the trust relationship is maintained between therequest originator and the service endpoint. The Service Router candefine an error handler to handle authentication, authorization, andservice failures of an endpoint, and can define alternative serviceendpoints to process the request, or define the manner in which failureinformation is returned to the request originator. In some embodiments,the Service Router can have a plurality of failure handlers that providedifferent failure handling semantics.

In some embodiments, the Service Router caches adapter definitions andassociations of adapters to endpoints. This improves performance (butcan require an application reload if the adapters are changed). In morespecific embodiments, the service owner can create adapters for eachservice endpoint that can called by a plurality of Service Routers. Eachadapter also can be shared between a plurality of endpoints.

While there is generally an adapter specified for each endpoint, the useof an adapter is not required in embodiments where the initial messageis already in the correct format for use by the service endpoint. Inthese embodiments, the initial message can be used withouttransformation. In other embodiments, distinct adapters are created forthe Request and another, distinct, adapter created for processing theresponse from the endpoint to the Service Router.

This second type of adapter is called a Response Adapter, and is used totransform the response from the endpoint into a format understood by aService Router. Alternatively, the same adapter can be used to processrequests as is used to process responses. In some embodiments of theinvention, Adapters transform a request message into the form requiredby the destination endpoint. This can involve at least one of atranslation of format, structure, and transmission protocol, and canadditionally require obtaining or creating new or additional securityindicia to support the new format, structure, and transmissionprotocols. The format translation is represented as flow 5 in FIG. 10.

In some embodiments, the adapter can translate an original requestmessage to a new message format using the SOAP format. The ServiceRouter then sends the adapter translated message to a specified serviceendpoint using the adapter-provided message transport (flow 6 in FIG.10). The sent message can optionally comprise a plurality of messages,and can further comprise additional elements including security indiciafrom the original message and/or the security indicia of at least one ofthe request originator, service resolver and registry, adapter, and/orother services associated with processing the sent message.Alternatively, the security indicia used can be provided from analternative source such as a service resolver and registry. Whichsecurity indicia to use is configurable when the service router isconfigured.

It is assumed in this embodiment that some form of authentication isrequired in order to invoke the remote endpoint. The authentication cana simple username and password passed in a SOAP Header, as sophisticatedand mutually authenticated SSL connections along with system identifiersand keys, a SAML artifact, or can be based upon other authenticationtechnologies. Alternatively, the authentication can be based upon thesending Service Router component's ID, or other information. In otherembodiments, no authentication is required and the authenticationmaterials are omitted.

The endpoint processes the request (step 7 of FIG. 10) and returns aresponse (step 8 of FIG. 10) to the Service Router. In some embodiments,the response message is optionally processed by a Service Router usingan optionally specified response adapter. The response adapter isfunctionally similar to the adapter described above, and is managed bythe Service Router in the same manner as other adapters.

In some embodiments, the response adapter executes the post-processinglogic (step 9 of FIG. 10) including data checks, calculations,replacements and formatting. The final objective of the response adapteris to generate a response message (step 10 of FIG. 10) to a ServiceRouter that is consistent with all messages returned by a Service Routerto client applications. The Service Router then processes the responseand returns it to the client (step 11 of FIG. 10). In some cases, SOAPFault messages are returned. This can occur when the original requestwas in SOAP format, and one or more processing steps were notsuccessful. In some alternate embodiments, the response includes thestorage of the Fault messages in the Active Voucher that was used toinvoke the remote endpoint. In these cases, the fault message cancomprise one or more of the elements related to the transactions, suchas:

-   -   Transaction ID    -   User Message    -   Status    -   Last Updated Date/Time    -   Initiation Date/Time

In some embodiments, a response from the endpoint (or Service Router) issubsequently transformed into a message block that is used to updateActive Vouchers or inform other server-side process. The response is astandard response from a Service Router and will include at least onemessage block that contains user friendly information about the statusof the request and/or the results of the request. This serves thepurpose of the original Download ID that was received from MobileStreams and entered in the Active Voucher. The message block and otherresponse details is placed in a content tf:Stub element attached to theActive Voucher. In some embodiments, other information can be placed inthe tf:Stub element and attached to the Active Voucher.

The response from the Service Router is, in some embodiments, a standardDCE status along with a message block that can be processed by a DCEapplication. A DCE application can update the Title with the contents ofthe message block. For example, if an OTA service request was made, theresponse can include a transaction identifier. In this case, thetransaction identifier can be placed in the resulting Title (e.g. usersActive Voucher) for tracking purposes.

An example response fragment from an XML formatted message is shownbelow:

-- <xs:element name=“TtsResponse” type=“xs:anyType” > --  <xs:complexType> --     <xs:sequence> <xs:element name=“TransactionId”type=“xs:NMTOKEN” minOccurs=“0” /> <xs:element name=“TransactionIdLabel”type=“xs:token” minOccurs=“0” /> <xs:element name=“Message”type=“xs:string” /> <xs:element name=“Method” type=“xs:token” /><xs:element name=“TimeInitiated” type=“xs:dateTime” /> <xs:elementname=“TimeCompleted” type=“xs:dateTime” /> </xs:sequence></xs:complexType> </xs:element> <xs:element name=“System”type=“tp:systemType” <xs:element name=“User” type=“tp:userType” /><xs:element name=“Status” type=“tp:statusType” /> </xs:schema></wsdl:types> -- <wsdl:message name=“ServiceRouterRequest” > <wsdl:partname=“TtsRequest” element=“tp:TtsRequest” /> </wsdl:message> --<wsdl:message name=“ServiceRouterResponse” > <wsdl:partname=“TtsResponse” element=“tp:TtsResponse” /> </wsdl:message> --<wsdl:message name=“TtsSystem” > <wsdl:part name=“System”element=“tp:System” /> <wsdl:part name=“User” element=“tp:User” /></wsdl:message> -- <wsdl:message name=“TtsStatus” > <wsdl:partname=“Status” element=“tp:Status” /> </wsdl:message> -- <wsdl:portTypename=“ServiceRouter_PortType” > -- <wsdl:operationname=“ServiceRouter” > <wsdl:input message=“tp:ServiceRouterRequest” /><wsdl:output message=“tp:ServiceRouterResponse” /> </wsdl:operation></wsdl:portType> -- <wsdl:binding name=“ServiceRouter_Binding”type=“tp:ServiceRouter_PortType” > <soap:binding style=“document”transport=“http://schemas.xmlsoap.org/soap/http” /> -- <wsdl:operationname=“ServiceRouter” > <soap:operation soapAction=“ServiceRouter” /> --<wsdl:input> <soap:header message=“tp:TtsSystem” part=“System”use=“literal” wsdl:required=“false” /> <soap:headermessage=“tp:TtsSystem” part=“User” use=“literal” wsdl:required=“false”/> <soap:body encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”use=“literal” /> </wsdl:input> -- <wsdl:output> <soap:headermessage=“tp:TtsStatus” part=“Status” use=“literal” /> <soap:bodyencodingStyle=“http://schemas.xmlsoap.org/soap/encoding/” use=“literal”/> </wsdl:output> </wsdl:operation> </wsdl:binding> -- --<wsdl:servicename=“ServiceRouter” > -- --<wsdl:port name=“ServiceRouter Port”binding=“tp:ServiceRouter_Binding” > <soap:addresslocation=“https://builder.navio.com/tts/service/ServiceRouter” /></wsdl:port> -- <wsdl:port name=“NonSecureServiceRouter_Port”binding=“tp:ServiceRouter_Binding” > <soap:addresslocation=“http://builder.navio.com/tts/service/ServiceRouter” /></wsdl:port> </wsdl:service> </wsdl:definitions>

In some embodiments, a plurality of responses can be processed by theService Router in response to a single request message. It will beappreciated by the reader how a plurality of response messages can beprocessed using the scheme described above.

6.4.2.1.8.3 Multiple Services

The previous embodiment illustrated the basic flow supported by aService Router. In such embodiments, the adapters are responsible forsending and receiving, and the flows can easily be extended to supportmore complex flows as well as coordinated activities. FIG. 11 depicts aslightly more complex flow for an alternative embodiment of theinvention:

Flows (1) thru (9) proceed as described above for FIG. 10. Afterreceiving the response back from a first endpoint and processing it(step 9 of FIG. 10 and FIG. 11), the Service Router or adapter can makeadditional calls to other endpoints. In this example, no additionaladapters were selected, and the message(s) are forwarded from theService Router/adapter to a second endpoint (step 10 of FIG. 11), wherethey are processed (step 11 of FIG. 11), and returned to the ServiceRouter/adapter (step 12 of FIG. 11). In some embodiments, apre-processing step is inserted between steps 9 and 10 of FIG. 11 in amanner consistent with step 5 of FIG. 11.

Processing continues with a post-processing step 13, an adapter response(step 14), and a response to the client (step 15). These steps areanalogous to steps 9, 10, and 11 of FIG. 10.

It should be noted that the Service Router itself can make the furthercalls to additional endpoints after the response is received from thefirst adapter.

In each case, the decision as to which message(s) to send to the nextprocessing step is made, at least in part, on the basis of the servicedefinition contained within at least one of a request, title, serviceresolver and registry, or Service Router.

6.4.2.1.8.4 Cascading Services

Cascading services are a still more complex variation of a ServiceRouter flows, and can be used to coordinate complex activities whileabstracting the complexity into two or more “compartmentalizedservices”. One embodiment of the invention using such Cascading Servicesis illustrated in FIG. 12. In FIG. 12, a Service Router is being calledby itself. This can be a recursive call, or can be a call to invokeanother service that is abstracted by a Service Router. In thisparticular example, the second Service Router involved in the activityis a completely separate instance operating in a distributed andfederated environment. In other embodiments, the second Service Routeris the same instance as the first Service Router.

Flows (1) thru (9) proceed as described above for FIG. 10. Afterreceiving the response back from a first endpoint and processing it(step 9 of FIG. 10), the Service Router or adapter can make additionalcalls to other endpoints. In this example, no additional adapters wereselected, and the message(s) are forwarded from the ServiceRouter/adapter to a second endpoint (step 10 of FIG. 12). The secondendpoint is, in this example, another Service Router, which processesthe request as described in FIGS. 10 and 11, with a response beingreturned in step 18 of FIG. 12. In some embodiments, a pre-processingstep is inserted between steps 9 and 10 of FIG. 12 in a mannerconsistent with step 5 of FIG. 11. Processing continues with apost-processing step 20 of FIG. 12, an adapter response (step 21), and aresponse to the client (step 22). These steps are analogous to steps 9,10, and 11 of FIG. 10

In a more detailed embodiment the logic expressed either in therequesting Title, in the Service Definition, or a combination of the twois as follows. A Service Router makes calls to other Service Routers inorder to complete an activity. Each service implemented and handled by aService Router instance can be equally complex and can rely onsubsequent cascading calls. At a high-level each Service Router instanceencapsulates the processing logic for an activity and ultimatelyabstracts the complexity away from upstream implementations. In thesimplest embodiment, someone who is deploying a new activity need onlyknow what services to call and in what sequence and not how each serviceis implemented.

6.4.2.1.8.5 Adapters as Service Endpoints

In some embodiments, the adapter is used as the service endpoint ratherthan the adapter being used to invoke a remote endpoint. This isillustrated in FIG. 13. There, the adapter simply performs someprocessing logic in lieu of transforming the message and forwarding itto an external service. For example, the adapter can be used forinformation services such as delivering pretty-print versions of theTerms of Use or Privacy Policy statements.

6.4.2.1.8.6 Provisioning a Service Router

A Service Router may be provisioned as any other trusted service. Thefollowing steps can be used to provision a Service Router:

1. Setup an account for a Service Router. Since a Service Router uses anIdentity Provider for authenticating itself to remote endpoints, aService Router must first authenticate to a Identity Provider

2. Register an account for a Service Router using the Active Viewer orthe Merchant Registration form. In some embodiments, this account is nodifferent than any other account in the system. Other embodiments candistinguish “system” or “application” accounts from other accounts inthe Identity Provider.

If no account is setup, or the configuration is wrong, a Service Routerwill still function but it will not be able to authenticate itself toendpoints that depend on the SAML Artifact and the Identity Provider.

3. Configure a Service Router's configuration materials. In someembodiments, these are stored in the web.xml file. Configurations ofeach Service Router are implementation dependent. The followingparameters are generally configured:

-   -   maxRetries—Used only when the remote endpoint supports SAML        Artifact authentication. This parameter determines the maximum        number of times a Service Router will retry a login to the        Identity Provider and a subsequent endpoint request. The relogin        attempt is done everytime the SAML Artifact (or session)        expires. The default is 2.    -   createStubUrl—Specifies the URL endpoint for the Create Stub        service. This is generally the CreateRecordStub servlet on the        Title Manager.    -   identityProvider—Specifies the URL for the Identity Provider        Login service where a Service Router can log itself into the        system.    -   serviceAccount—Specifies the username (i.e. email address) for a        Service Router account on the Identity Provider.    -   servicePassword—Specifies the password for a Service Router        account on the Identity Provider.

A Service Router can interact with an external Web service if Adaptersfor that service are available. In some embodiments, these adapters aredeveloped ahead of time and are defined in a Service Definition in theService Resolver and Registry. In order embodiments, adapters can bedynamically generated. For example, an adapter reference can be to aService Router or other Web service that generates the correct adapteron demand. This can be accomplished by a XSLT used to generate anotherXSLT based on logic embedded in the XSLT and information being passed inthe source document.

In an embodiment using SOAP messaging, the Adapters (both Request andResponse) are XSLT stylesheets that format the request to the endpoint,and format the response from the endpoint.

1. Create a Request Adapter as part of the DCE build. The RequestAdapter must expect the initial request to a Service Router (SOAPEnvelope) as the source document. A Service Router request generallycomprises a tf:Title element containing the Title being redeemed and theRight element indicating what right is being redeemed. Optionally, therequesting application can provide a RequestContext element thatcontains request specific information that will vary from request torequest. The adapters can use this information if it isanticipated/known ahead of time. As an example, the RequestContextelement can contain purchase information if the Title is being redeemedas part of a purchase. The Request Adapter must handle authenticationrequirements for the external endpoint. If a username and password isrequired, then the adapter builds the correct elements in the SOAPEnvelope to authenticate the request. For example, the adapter placesthe athenticating material in a SOAP Header. The exception to this iswhen the external service uses the DCE Identity Provider forauthentication. In some embodiments, a Service Router automaticallyembeds a SAML Artifact in the SOAP Header. Adapters can also useextension mechanisms to make processing calls to external applications.For example, an adapter can be configured to call a java class/method ofan external application. Other types of external calls can be similarlysupported by an adapter.

2. Create a Response Adapter using the example provided as part of theDCE build. The Response Adapter takes the response from the endpoint andputs it into a normalized form for the DCE to understand and process.The response from the endpoint is handled by the requesting application.

Both the Request and Response Adapters must conform to the standards andguidelines established for these stylesheets, otherwise an error canoccur and the stylesheets can be rejected by the system.

3. Once the Request and Response Adapters are created, they must belocated in a repository accessible by the DCE.

4. A Service Router makes use of the Service Resolver and Registryservice for looking up external Web services and retrieving servicedefinitions. The Service Resolver and Registry entries must be setupprior to using a Service Router. To setup the Service Resolver andRegistry entry or entries follow the steps outlined in the ServiceResolver and Registry section. When the Service Resolver and Registryhas been setup with the correct Service Definition, make note of theservice definition (name, alias, or Document ID) that was assigned theservice.

5. Ensure that all Titles that need to use a Service Router have thecorrect entries in their redemption rights. For example, PolyphonicRingtone Products need to reference the correct Service Router URL andinclude a reference to the Service Definition (e.g. Document ID, servicedefinition name, or service alias). In one embodiment, the followingsteps are used to setup the Titles:

Edit an existing, or create a new mapping template that is used for thetitle publisher batch load process. The mapping template will ensurethat the published titles are constructed properly. A sample mappingtemplate includes global variables for the RegistryUrl,ServiceDefinition, ServiceType and OnBuyMethod. These global variablesrefer to information that must be included in the Title and are used bythe mapping template to create the ‘issue’ right of the Product. The‘issue’ right is responsible for creating all Active Vouchers.

The ServiceRouterEndpoint points to the publicly available URL for aService Router as this is used by client applications in order to invokea remote service (for example, a redeliver). The URL will generallyfollow this pattern:http://builder.navio.com/tts/servlet/service/RouterClient.

The ServiceDefinition is the Document ID, service definition name, orservice name alias from the service Product Title as indicated in theprevious Service Resolver and Registry step.

The ServiceType is the type of service that this refers to and is alsoobtained from the Service Resolver and Registry. In XML-basedembodiments, a service type is defined using a namespace. Examples ofservice type namespaces are provided above.

The OnBuyMethod variable is used to indicate what redemption rightshould be invoked when a purchase is complete. The Lockbox applicationwill automatically invoke this right after a successful transaction. Asan example, for ringtones, the OnBuyMethod should be ‘redeliver’.

The mapping template also has a reference to the OnBuyComplete logicsheet. This logic sheet is used by the Lockbox at the end of the buyprocess to determine what should be executed and how it should beexecuted. An example of a default logic sheet is an XSL script.

With the mapping template complete, the Products are loaded using thetitle publisher or are updated with a modified mapping template. Ensurethat every merchant that intends to use a Service Router with theirtitles has access to the mapping template.

Modify the Merchant Pass for the merchant and add access to the mappingtemplate edited or created above. A Service Router approach can requireadditional setup and configuration but it is more extensible than theprevious right of creating custom logic sheets for each type of Title,or action for each type of Title. There is preferably only one logicsheet shared by all Titles and the control logic is handled by adapters.Additionally, service definitions are used to indicate what endpointneeds to be invoked and what adapters need to be used. Since Titlesrefer to a service definition and not directly to a logic sheet, themerchant can easily change the definition in the Service Resolver andRegistry and have the changes automatically propagated throughout thenetwork. With the registry approach, there is no need to modify Titlesthat are in circulation, including Products and Offers. This featureprovides an extensible and flexible environment by placing more controlin the merchants and/or operators hands. If a service signature changes,or the service parameters are enhanced, or a new operator becomesinvolved, the definition in the registry is used to effect the change.

6.4.2.1.8.7 Adapters

As described above, Adapters can be hard coded or can be implemented asscripted transforms. The following embodiment details an XML-baseddescription of an adapter transform. The base adapter framework importsdescriptions of this type to manage the transformation and sending ofmessages. The base adapter XSLT(s) imported by the adapters can supporta “send message” functionality and various message types such as SOAP,POST, GET, HTTP/XML, SMTP, etc.

As an example, the following basic SendMessage function supports sendingSOAP messages directly from a Request Adapter:

<!--  This template will build and send a ProcessMessage and return anodeset.  For this template to work correctly, the endpoint must returnXML. Note,  since this template uses XALAN Java extension, it will onlywork on an  Xalan processor.  The Header and Footer passed to thistemplate must be a String and not a  node-set. --> <xsl:templatename=“SendMessage”>  <xsl:param name=“endpoint” select=“‘’”/> <xsl:param name=“action”select=“‘’”/>  <xsl:paramname=“header”select=“‘’”/>  <xsl:param name=“body”select=“‘’”/> <xsl:variable name=“message”>   <Message>    <Endpoint type=“url”method=“post”>     <xsl:value-of select=“$endpoint”/>    </Endpoint>   <SOAPAction>     <xsl:value-of select=“$action”/>    </SOAPAction>   <Body>     <soap-env:Envelopexmlns:soap-env=“http://schemas.xmlsoap.org/soap/envelope/”>     <soap-env:Header>       <xsl:copy-of select=“$header”/>     </soap-env:Header>      <soap-env:Body>       <xsl:copy-ofselect=“$body”/>      </soap-env:Body>     </soap-env:Envelope>   </Body>   </Message>  </xsl:variable>  <xsl:copy-ofselect=“svc:sendDocumentMessage($message)”/> </xsl:template>

As indicated in the example, a Xalan Java extension(svc:sendDocumentMessage ($message)) is used to send the SOAP messageand this particular example only supports SOAP calls. The Java call thatis made is to a Service Router utility method that calls the DCE'sProcessMessage class to handle and send the message. This basiccapability must be extended to support the other ProcessMessage types(e.g. POST, GET, and SMTP) and to provide a cleaner integration withXalan. Furthermore, the “send message” capability needs to be isolatedfrom other base templates as it will have different implementationsdepending on the XSLT processor used (such as Datapower XS40 or Saxon).

A sample RouterTemplate.xsl stylesheet is provided to demonstrate themessage building capabilities required by the base templates. This isfor example purposes only and does not depict how the template should bewritten or implemented.

6.4.2.1.9 User Interfaces

A TPE may provide one or more instances of user interface (UI)applications and components. In some embodiments, the UI components arethe application interface, such as the interface provided by atitle-enabled merchant system or other title enabled application. Inthese cases, the user interface is provided by the application, and maybe constructed using traditional user interface techniques such as web,thin client, or thick client interfaces.

In other embodiments, a TPE exposes titles to users and requires atitle-specific user interface to be exposed. Two examples of TPEcomponents, a “title helper” and an “Active Viewer” application, provideuser interface components in various embodiments. A Title Helperprovides a web-based interface for title-enabled applications that donot otherwise have a TPE interface, and provides an interface betweenthe title-enabled applications and a TPE. An Active Viewer (AV) providesa distributed TPE and integrated user interface.

A user interface may be invoked in several ways. In a first embodiment,the user interface is invoked by the user when they select a userinterface-enabled indicator on a web site or as part of an advertisingbanner. In other embodiments, the User interface may be invoked when theuser selects an application link that identifies an instance of a userinterface to be run. Alternatively, a user interface may be directlycalled by an external applications program or web site, or may bestarted based upon recognition of specific received content. Examples ofthe latter may include starting the User interface on the basis of afile type association, MIME type, or upon receipt and recognition of atitle, upon receipt an out-of-band communications media such as e-mailor instant messaging containing a title. Another example is distributionof content on a network such as P2P in a format that can be recognizedand invoked by client applications such as P2P applications. These filesare distributed in a format recognized by the application. When opened,the application displays the contents, at least in part using Userinterface. Alternatively, the User interface may be invoked at devicestartup and may be always running. In implementations where Userinterface functionality is embedded in other applications or operatingsystem components, the User interface and its components may be directlycalled by the applications (such as a media player licensing interface)or by operating system components within which the User interface isembedded. For example, a user interface may be invoked by the MicrosoftMedia Player license acquisition page. Alternatively, the User interfacemay be involved by a file browser such as Windows Explorer. Such Userinterfaces can be provided using the techniques described herein andmethods known to those having skill in the art.

In some embodiments, a TPE's user interface may be integrated with websites and accessed from computing devices using standard Internetprotocols including HTTP, HTTPS, and WAP. In some embodiments, the Userinterface may be launched from an existing web site by naming the Userinterface in a link, or by naming a user interface operating context ina link (which loads the user interface by association), by specifying itusing a scripting language such as JavaScript, or by other means wellknown to those skilled in the art.

In some embodiments, a Title Helper or Active Viewer may be partiallydeployed as a web browser plug-in that scans web pages and other contentsources as they are loaded, watching for links that name a userinterface, an operating context, or title. If an appropriate link isdetected, the web browser plug-in rewrites the web page on the fly,adding the necessary scripting language (such as Javascript) to the webpage to display the Title Helper or Active Viewer indicator shown in theaccompanying screen shots. The Title Helper or Active User interfaceindicator provides a visual indication to the user that a page is titleaware.

In one embodiment, the user interface is provisioned with a list of websites from which it is authorized to be launched. The user interfacemay, depending upon configuration, choose to not launch, launch in“insecure mode” (e.g. the trust indicator is not set), or may display apopup window indicating that the user interface is being inappropriatelylaunched. In one example embodiment, a user interface may require atitle to launch, said title may alternatively specify a operatingcontext to be used.

In other implementation strategies, a Title Helper or Active Viewer mayrespond to content being downloaded. This content is often identified bycontent meta-data, such as file type, file extension, and MIMEextensions. The Title Helper, Active Viewer, browser, operating system,or other component may monitor downloaded content and start a userinterface when content that matches a specific content type isdownloaded. For example, the user interface may be started when a MIMEtype that identifies a title is downloaded. Alternatively, the userinterface may be started when a file with a specific file extension isdownloaded. Furthermore, MIME encoding may additionally describe one of:a user interface operating context associated with the downloadedcontent, a user interface title name associated with the downloadedcontent, or a mime-type that is used to identify content that may bemanaged using a Title Helper or Active Viewer. Some examples of theabove-mentioned MIME-encoding techniques are provided below:

-   -   X—Operating context: 1234567890    -   X—Title: http://location-goes-here    -   X—Title: (body of title follows here)    -   X—Protected: (an example of a MIME flag)    -   Content type: X—navio/X—subtype

It should be understood by those skilled in the art that the names andvalues of the MIME entries may be configured as part of theimplementation without affecting the scope of disclosure. The aboveexamples describe responding to a wake-up message may be equally appliedto SMS, IM, or other messaging protocols on other computing devices suchas desktop computers. The above examples of monitoring downloadedcontent for MIME information may be applied equally well to anysituation in which MIME-specified content is available, including filedownloads from the Internet.

Another example of invocation is the invocation of a right to contactcustomer support via an online chat. In this case, the right allows theuser to invoke the contact right and runs a supporting plug-in thatprovides a chat interface with the user. A title provides the underlyingright for contacting customer support, and specifies a operating contextthat specifies the look and feel of a chat or IM system. Alternatively,the operating context may specify using a customer preference for chator IM application.

6.4.2.1.10 Title Helper

The user's experience in effecting transactions on the Internet may begreatly enhanced by the Title Helper of the present invention whichintegrates seamlessly with title-enabled sites, e.g., e-commerce sites,and provides a consistent interface for all transactions with which theuser is comfortable. According to one subset of functionality, the TitleHelper provides a window into a user's rights portfolio (i.e.,collection of titles) which may be stored remotely on one or moreservers (e.g., at a title-based transaction site as described herein).As discussed elsewhere herein, the rights portfolio may actually includeone or more portfolios which may be viewed individually or as a singleportfolio. The Title Helper allows the user to manage, collect, trade,transfer, redeem, group, and share the titles in the portfolio.

A simple yet powerful user interface to the title manager, referred toherein as the Title Helper, is shown in FIG. 14 as an independentoverlay window on the user's machine. The Title Helper is a serviceapplication which acts on behalf of the user in the electronic realm toeffect title-based transactions. In facilitating such transactions, theTitle Helper is operable to act as a proxy for the user to varyingdegrees. The Title Helper represents the user on the Web, becomingactive when invoked by the user (or by a title-enabled site with whichthe user is interacting) to facilitate title-based transactions. Wheninvoked, the Title Helper manages and controls access to the digitalassets (in the form of titles) in the user's rights portfolio. It makesthe terms of a proposed transaction visible to the user, and ensuresthat the parties to the transaction adhere to those terms. Thiscapability is particularly valuable in view of the fact that the typicalconsumer on the Web is largely unaware of the underlying terms or thetransfer of information associated with the many transactions in whichthey routinely take part.

In some embodiments, the Title Helper goes beyond proxying only thetransactions on pages configured to use the Title Helper and addsadditional functionality allowing it to act as a ‘trust shield.’According to more specific embodiments, a trust shield functions tofilter the web page a user is viewing, recognizing the purchasing pageand html and javascript on the page, and reinterpreting it on behalf ofthe user. Thus a user would be ‘shielded’ from a web site that did notin any way specifically invoke the Title Helper. The Title Helper wouldact as a proxy to purchase on behalf of the user, and debit his accountin any of a variety of ways such as, for example, from a credit card, orfrom digital cash or coupons.

In another example, the Title Helper can analyze and interpret webservices that are referenced on a page and that can be invoked by theuser. For instance, the Title Helper can recognize form elements andform submissions. In this case, the Title Helper can retrievedefinitions for the web service including interface definitions andinformation to choreograph a transaction with the web service. The TitleHelper can be used to invoke these services on behalf of the user. Webservices can be defined and placed on a registry for discovery or can beinterpreted by the DCE which the Title Helper communicates withdirectly. According to various embodiments, the Title Helper is operableto act as a privacy shield such that the user does not need to revealtheir identity to the party or site with which they are transacting.

The interface on which the Title Helper is superimposed or overlaid maybe a Web page generated by a conventional Web browser application. Thefollowing description assumes such an approach for illustrativepurposes. However, it should be understood that the underlying interfacemay be generated by any of a variety of programs without departing fromthe scope of the invention. For example, the functionality of the TitleHelper may be effected on a small device such as a credit card or ATMreader which is typically used to authenticate a user and drive apurchase via their credit card. The user would typically enter theiruser name and password on the device, a magnetic card, fingerprintreader or RFID, etc. and then various aspects of the web basedfunctionality would be accessible via the device.

Referring now to FIG. 14, Title Helper interface 1401 has two states,dormant 1403 and active 1404. In the dormant state, Title Helper isalmost entirely hidden with only a minimal amount of informationdisplayed to indicate its presence, thus not interfering with thecontent on the web page 1402. When a predetermined event happens (e.g.,the user browses a title-enabled merchant site), or the useraffirmatively invokes the Title Helper (e.g., with a key stroke or byplacing a pointer device over the dormant Title Helper), the TitleHelper becomes active. In the active mode the Title Helper expandsitself to a large enough area that it can display any relevantinformation, while still only obscuring a small part of the underlyingapplication interface, e.g., a browser interface.

In this case the user never completely leaves their originatingenvironment and transactional context is always maintained. This is aunique value proposition of the dormant and active states of the TitleHelper since the user remains on the originating site. The user canresume exactly where they left off when the transaction completes andthey are always visibly reassured. The merchant is also provided with anopportunity to present to the user additional information on the webpage that can reassure them about the site they have visited and thattransactional integrity will be maintained.

According to various embodiments, the Title Helper is a lightweightengine (e.g., an overlay, plug-in, or virus application) for processingtitles on behalf of applications which are not themselves title-enabled.According to a specific embodiment, the Title Helper comprises aMacromedia Flash application. The Title Helper can integrate relativelyeasily with applications which are not operable by themselves to conducttransactions using titles, thereby enabling such applications to enjoythe advantages of title-based transactions with little or no alterationof the code of the underlying application. In some cases, and dependingupon the degree of coupling between the two, the underlying applicationmay not be aware of the existence of the title helper. In general, thetitle helper is a mechanism which allows any site or application tobecome title-enabled.

For example, the Title Helper could work in conjunction with anindividual's Web site and a title-based architecture as described hereinto enable the individual's site to engage in commercial transactionswithout having to incorporate sophisticated commercial capabilities intothe site. In another example, the Title Helper could work with a digitalmusic player to enable the user to browse, select, sample, and pay formusic tracks. The range of applications and utility of the Title Helperallows the user to readily enjoy the security and efficiency of engagingin title-based transactions for virtually all their online transactions.

According to various embodiments, the Title Helper may be employed tofacilitate virtually any application becoming title-enabled, and mayhave various degrees of coupling with the underlying application. Forexample, the Title Helper may be a tightly-coupled software module whichis integrated directly into the code of the application. Alternatively,the Title Helper may be a plug-in which is more loosely coupled with theapplication, taking advantage of, for example, available exposedinterfaces of the application.

According to other alternatives, the Title Helper may be very looselycoupled with the application. For example, hyperlinks associated with anapplication can be redirected to URLs associated with the Title Helperwhich may be stored locally or located on a remote device. Such ahyperlink might be a “buy” link which a user would select when he wantsto purchase digital content. The link might then redirect the user'sbrowser to a 3^(rd) party title-based architecture which transparentlyfacilitates the transaction using titles. The 3^(rd) party site servesup the Title Helper interface which then appears on the user's screen tofacilitate the transaction using, for example, payment or walletfunctions as described herein. Those of skill in the art will appreciatethat the degree and nature of coupling and the functionalities providedmay vary considerably without departing from the scope of the invention.

Regardless of the degree of coupling and according to variousembodiments, the Title Helper may facilitate many of the functionalitiesdescribed elsewhere herein. For example, the Title Helper may facilitatepayment and wallet functions, and title management functions (i.e., theintelligent presentation and management of titles). Specific TitleHelper capabilities which enable the capture of user input (e.g., PINentry and data entry) allow user information to be protected from themerchant or more importantly to explicitly define the type ofinformation required by the merchant for the transaction to complete.For example, the Title Helper can accept a PIN obtained through aphysical retail transaction to convey value during an onlinetransaction. Additionally, the Title Helper can present a form detailingthe information required by the merchant such as mobile information.

The Title Helper is also operable to facilitate synchronization betweentitles and data associated with any underlying application which thetitles represent. For example, the Title Helper can facilitate transferof titles to/from local devices for offline storage or for transport viaexternal mechanisms. In this case, the Title Helper acts as a secureintermediary process between the DCE and the local machine, allowingtransfer of titles to a local device such as a hard drive, secure flashdrive, mobile device, or other device. Optionally, the Title Helper canprint the titles to provide a hard copy version.

The Title Helper may also facilitate other functions relating to onlinetransactions such as, for example, shopping cart functions, escrowcontrol functions, privacy functions, etc. According to someembodiments, the container and plug-in capabilities of the Title Helperprovides an operating platform for functionality that can be plugged indynamically and during runtime. This allows the Title Helper to beextended and offer new functionality. For example, a video component canbe added to the Title Helper for training and instruction, while aninteractive audio-video component can be plugged in to allowtransactions to occur over other channels and media.

According to specific embodiments, the Title Helper provides a singleview and interface for a user's federated identity, where their profileinformation is spread among many parties. In this case, titles are usedto refer to and grant rights to identity information stored and managedby the other parties. The Title Helper provides an interface to presentthe identity information, as well as use the information during atransaction. The Title Helper may also be an effective tool forprovisioning or coordinating provisioning services. In this case, theTitle Helper can be used to provision new accounts or new services thatare required as part of, or in conjunction with the transaction. Forexample, if a Web site only accepts payment in euros, the Title Helpermay employ a currency exchange service or mechanism to effect atranslation between the user's funds in U.S. dollars (as represented bytitles) and the currency required by the site. This may be effected withor without interaction by the user and does not require that theunderlying site be a title-enabled site.

As mentioned above, the code for the Title Helper may reside in avariety of places. For example, the Title Helper may reside on theuser's machine and be associated with or integrated to some degree withthe user's Web browser. Alternatively, the Title Helper may be served upby a title transaction site, e.g., the site hosting the user's rightsportfolio. Still another alternative involves the Title Helper beingserved up by the specific title-enabled site with which the user istransacting.

According to some embodiments, the integration of the Title Helper witha title-enabled e-commerce site is facilitated by a “shopping cart”functionality in the Title Helper. This functionality allows the user tocollect offers for goods or services at, for example, an e-commercesite. Each offer is a title which represents the right to buy thecorresponding goods or services. The shopping cart functionality of theTitle Helper allows the user to see these titles representing the offersand the terms of each. Thus, the Title Helper provides a window on theterms of a proposed transaction, as well as the necessaryfunctionalities to facilitate the transaction. This aspect of the TitleHelper also removes the shopping cart functionality from the control ofthe merchant site to the control of the user.

As will be understood, the presentation of the actual terms of aproposed transaction to the user is beneficial to both the user and histransaction partners in a number of respects. For example, as mentionedabove, it is relatively common for a consumer to be unaware of theactual terms of transactions in which they routinely engage on the Web.There is an inordinate (and oftentimes unjustified) amount of trustplaced by consumers that the parties with whom they transact are, infact, who they say they are, and are actually abiding by the terms theyare proposing. Because the actual terms of the deal are made explicit bytechnology not under control of the other parties to the transaction,the user is able to make informed decisions about whether to proceedwith particular transactions. Similarly, because the Title Helperprovides the ability to monitor and control what titles are transferredduring the course of a transaction, satisfaction of the actual terms ofthe transaction can be verified.

Because the Title Helper can contain a variety of monetary instruments,it can also translate between them and thus facilitate a purchase evenif the merchant site does not accept the monetary instruments the userhas at their disposal. If a user has, for example, digital cash, but thesite does not specifically accept that cash, the AV might translate theuser's cash into a credit on some other monetary instrument that isaccepted by the merchant and thus make the transaction. Furthermore,since in some embodiments, for example the ‘Trust Shield,’ the TitleHelper can act so as to proxy the entire purchase process, actingcompletely on behalf of the user such that the user's anonymity ismaintained.

As discussed elsewhere herein, transactions involving the exchange oftitles between or among multiple parties may be effected using atitle-based escrow process, e.g., the digital lockbox into which eachparty to the transaction transfers titles to a lockbox to facilitateconsummation of the transaction. According to some implementations,verification the contents of a lockbox may be achieved manually, i.e.,by each party viewing the contents to the lockbox.

According to some embodiments, additional escrow guarantees can beexpressed through the Title Helper. These may come at an additional cost(e.g., incurred by the merchant or passed through to the consumer). Ifthe escrow is providing a higher degree of guarantee, this can becommunicated by the Title Helper and interaction between consumer andescrow facilitated.

According to one such embodiment and as mentioned above, a site which isnot by itself title enabled may become titled enabled quickly and easilywith some relatively simple mechanisms. For example, an html link to aremote title transaction infrastructure such as those described hereinmay be embedded in one or more of the Web pages on the site. These linksare directed to the Title Helper and cause the Title Helper to bedisplayed in the browsers of users navigating the site. In addition,offer titles, e.g., in the form of XML documents, may also be embeddedin the pages of the site. These offer titles may be created by the siteoperator with reference to the appropriate specification, or may becreated using a title creation/publishing mechanism hosted elsewhere,e.g., at the remote title transaction infrastructure. The Title Helper,as a web browser plug in, can act to fill in the information on behalfof the user with an Title Helper account which is, in turn, ‘fed’ by theuser's stored titles.

In another embodiment, a title-enabled proxy server can be insertedbetween the user and the site which adds the code to the originatingsite's markup language (typically HTML) necessary to launch the TitleHelper and may modify specific merchant specific purchasing associatedmark up language.

In another embodiment the Title Helper can interpret the page of aparticipating merchant, and act upon user actions to purchase content.In this example, the Title Helper understands the actions the usertakes, such as a click on a buy link on the page, and adds the item tothe shopping cart. The Title Helper communicates the action to the DCEwhich in turn analyzes the action according to preset site contextestablished by the participating merchant. The DCE can directlyinterpret the action or communicate with the merchant to understand theaction. In this case, the action results in a generic offer beinggenerated for the purchase action. The generic offer is a title thataccepts purchase information, such as content name, price, and terms, atthe time of purchase. The information is verified by the DCE and appliedto the generic offer. The use of generic offers allows participatingmerchants to easily work with the Title Helper and escrow processwithout re-tooling their merchant sites and storefronts.Non-participating merchant transactions can also be accomplished withthis mechanism and the level of transaction integrity and guarantee canbe independently verified by the DCE operator and/or by a third party.

6.4.2.1.11 Active Viewer

An Active Viewer is a TPE application that provides a distributed TPEand user interface components. Its functionality follows that of a titlehelper. The Active Viewer extends the functionality of a Title Helper byenforcing TPE context semantics on the user interface. This enables atrusted user interface called an Active User Interface, in addition tolocal execution of one or more TPE components.

The Active User interface provide user interfaces for defined TPEapplications and may additionally have third-party applications defined,either within the Active User interface or by use of an operatingcontext specification and may link to these applications when sodirected by a user. The linking and subsequent execution of theseapplications may be a title expressed right event, and be subject to arights specification within a title object. An Active Viewer may be usedto provide a TPE to enforce title-based access control to specificservices and to mediate access to these services upon the basis ofrights specified in one or more titles.

In an example embodiment, a merchant who has a right to run a userinterface-Reporting service to generate a report of title-based usage oftheir electronic property may be provided this option upon the basis ofa specific title or voucher they possess. The title object may identifythe specific service, or may identify a specific TPE that includes thespecified service. The user may specify the report they desire by makinga service request within the specified TPE. In the specific example, theuser would click a button linked to a “Report” service provided by auser interface-Reporting server associated with a specific DCE. Theuser's rights as defined in the title may be used to further define therights over the report content itself.

Alternatively, a specific title or operating context specification mayspecify specific third party applications, such as a music player, chat,IM, or VoIP service that should be executed when a specific right hasbeen selected.

In some wireless and mobile environments, an Active Viewer may beassociated with a “wake-up” or other notification message. As oneskilled in the art will recognize, wireless mobile environments maydeliver a message to a mobile device as a “wake up” notification. Thesemessages may be delivered using any of SMS or other messaging systemscommon to the wireless and mobile devices. The wake-up notification mayinclude additional information, such as a specification for anapplication to respond to the notification using, a URI of a service toconnect to, a operating context specification, and other information.The mobile device, upon receipt of the notification message, wakes upand uses a device specific application to connect to a network servicein response to the notification. In an example embodiment, the mobiledevice may use a device-specific application, or an applicationspecified in the wake-up message, to respond to the “wake up” message.In a particular example embodiment, the application used to respond to awake-up message is the Active User interface. In an alterative exampleembodiment, the wake-up message may specify the Active User interface asthe application to respond to the wake-up message.

In alternate embodiments, the ‘wake-up’ message may include a operatingcontext specification, either embedded within the URI, or as anadditional data element included in the message.

One method of implementing a plurality of wake-up message responders isdescribed above, where the wake-up message specifies the desiredresponder. In other possible implementations, the device itself may makethe wake-up responder determination. For example, the device may providea selection mechanism in which the wake-up message responder applicationis determined upon the basis of at least one of: the sender of thewake-up message, at least some of the contents of the wake-up message,and device or user preferences stored in a profile in the device.Parameters to wake-up message responder application may be provided fromthe sender of the wake-up message, at least some of the contents of thewake-up message, and device or user preferences stored in a profile inthe device. These parameters may include a operating contextspecification, a title, or other User interface recognized information.

An example implementation might include a device that starts an ActiveViewer to respond to a wake-up request from a specific sender or groupof senders. Alternate implementation examples include recognizing aspecific URI, or part of a URI in the wake-up message and making theselection of a desired user interface on that basis. A part of a URImight include a operating context specification in the addressspecification or in the URL parameters, as illustrated below:

https://mysite.com/first-operatingcontext-reference/webservice.asp?my-operating context-name

In a further illustrative example, the identification of URI or senderinformation may be made on the basis of information stored in the device(e.g. a list of known trusted sites).

In various embodiments, the Active user interface manages at least onedisplay pane that is used by the Active Viewer component, a TPE, itsassociated components, and external services to display service optionsto a user and to collect and process input from the user. A display paneis a unique portion of a display, including a window or portion of awindow, used as part of an input-output operation supporting theinteraction between a user and a component of a title expressed rightprocessing environment. A screen of a display, a popup window, aslide-out or drawer display portion, and an application-defined form areall examples of a display pane. A display pane may be uniquelyassociated with a specific application, component, or service or it maybe shared between one or more applications, components, or services. Inone example implementation, the Active user interface may implement adisplay pane that provides an XForms compliant display. In other exampleimplementations, other display technologies such as SMIL or XAML may beimplemented as panes. Alternatively, the Active user interface mayprovide display panes that respond to a plurality of displaytechnologies, and may provide a plurality of display panes that respondto one or more disparate display technologies. Such Active userinterfaces can be provided using the techniques described herein andmethods known to those having skill in the art.

6.4.2.1.11.1 Operating Contexts and the Active User Interface

The set of resources required and/or desired to provide an aspect of aspecific title expressed right processing environment, including but notlimited to services, directories, components, applications, displaypanes, and user interface is called an operating context of the Userinterface architecture. A operating context is an alternate embodimentof a subset of the elements named by an operating context and describesat least one aspect of an operating context, and names, describes,references, or includes services, directories, applications, components,and user interface components required to provide the desired operatingcontext and user interface.

The operating context that the Active user interface should use for aspecific title expressed right processing environment or operatingcontext may be defined by the Active User interface configuration, byembedded operating context, by the location from which the Active Userinterface is invoked, or by a title requesting User interface services.

One or more operating contexts may be simultaneously referenced byand/or used by an Active User Interface. A user interface thatreferences a operating context may locate and load a operating contextin a variety of ways. First, it may have a well-known storage locationfrom which it loads a operating context. For example, a user interfacemay load a operating context from a local disk or memory store, anexternal disk or memory store, including an external repository site, orthe User interface may look up the location of a operating context usinga directory service, and then obtain a operating context either from thedirectory service, or from a third party source by using informationprovided by the directory service. Operating contexts that are loadedfrom locations external to a user interface where they may be subject totampering may be optionally verified and validated using techniquessimilar to those described above for verifying and validating Userinterface title expressed right processing environment components.

In some embodiments, a plurality of operating contexts may be loaded andsimultaneously operate within a Active User interface, each used todefine a disparate title expressed right processing environment. Inother embodiments, the User interface operates on a single operatingcontext at a time. A single operating context may be used to define aspecific operating context, or a plurality of operating contexts may becombined to define an operating context. The User interface optionallymay have a default operating context associated with it. If such adefault operating context is specified, the User interface uses thespecified default operating context in the absence of other operatingcontext specifications.

An operating context may be specifically associated with a collection ofservices that comprise at least part of a title expressed rightprocessing environment. A specific operating context may be associatedwith a specific service, a TPE, a TPE applications like the DigitalCommerce Engine (DCE), a specific DCE component, or with an externalservice. The association between a specific service or services and aspecific operating context may be made on the basis of a configurationspecification, a service specification, specified by the service, orbased upon the information returned from an external service. Oneexample of such an external service that may provide informationdescribing a required operating context is an identity provider. TheActive User interface, and attendant operating context specifications,defines the binding between backend services, UI and customer-facingapplication components, and binds these services and components with aspecific look-and-feel. This binding facilitates a unified andhomogonous user experience.

6.4.2.1.11.2 UI Specifications

An operating context specification of the view portion of a UIspecification comprises one or more optional properties. Each optionalproperty describes an attribute of the operating context, such as anidentifier, a version, a unique name, a rights specification, alocalization specification, and a unique location reference such as aURL. Some or all of these properties may be present in a specificinstance of a operating context. A operating context may also referenceone or more additional operating contexts in order to specify additionalportions of a title expressed right processing environment.Alternatively, the operating context may specify one or more namealiases. In some embodiments, a operating context may specify a propertythat provides for the cryptographic authentication of the operatingcontext itself. Such a property may comprise a cryptographic hash ordigest, such as those produced by well known algorithms such as MD5, ormay embody a SAML artifact, or a reference to a service that can providethe authentication materials.

Each operating context optionally comprises specification of, referenceto a view specification, or reference to a hierarchical definition thattaken together, comprise the specification for one or more views. Eachview specification optionally specifies at least one style sheet to use,at least one skins definition, an optional task map, including theoptional specification of at least one component to be loaded, andoptionally defines permitted process flows. Additional materials relatedto user interface specifications, including views, skins, style sheets,and class maps are described in U.S. patent application Ser. No.11/645,139 (Attorney Docket No. API1P009) incorporated herein byreference above.

6.4.2.1.11.3 Display Panes

In a preferred embodiment, the User interface provides one or moredisplay resources, called panes, to application components. In oneembodiment, a pane may comprise a window in a windowing operatingsystem. In an alternate embodiment, a pane may be part of a screen, ormay comprise a drawing area of a larger window.

FIGS. 15 a, 15 b, 15 c, and 15 d illustrate an example of the userinterface, comprising multiple panes, a first pane which is displayedwhen the User interface user accesses the User interface (FIGS. 15 b, 15c), and a second pane which is made visible when the User interface user“pulls out” the drawer to expose additional content referenced by thefirst pane (FIG. 15d ). The “drawer” may be “pulled out” or “pushed in”by the user, or may be optionally “pulled out” or “pushed in” undercontrol of the User interface.

An operating context specification maps components, applications, thedesired user interface look-and-feel (e.g. a skin), services, andservice outputs to a specific display panes. In some embodiments, acontroller component may be used to assist with mapping of theseelements. In some cases, the controller component may be used totransform service outputs into a format usable within a operatingcontext specification.

Extensible features of the User interface also include the ability todefine an operating context's look and feel using “skins” and to developbranded versions of the Active User interface that enable and/or disablespecific features and component capabilities within each specificoperating context.

Furthermore, a user interface may have its “look and feel” bound to it,so that it provides a specific look and feel when operating, or whenoperating within a specific web site and/or service. Alternatively, thelook and feel may be bound when User interface is operating as acomponent in conjunction with a third party applications such as a musicuser interface. Alternatively, the User interface may take at least partof its look and feel from the configuration of the web site, service, orthird party application to which it is bound. These bindings areeffective either for the entire instance of the User interface, or for aspecific display pane of the User interface.

For web sites, services, and third-party applications (collectively, asource) that are “User interface” aware, the source(s) may provide aspecification (e.g. a operating context), a reference to a specification(e.g. , a link to the operating context, skin, or style sheet), or theidentification information of a specification (e.g. a operating context,skin, or style sheet search specification, or parameters to a searchservice) that specifies the desired components, bindings, and look andfeel. Alternatively, a source may provide a unique identifier that theActive User interface maps to a defined configuration (e.g., anidentifier for a provider of child content that defines a specificoperating context, skin, or style sheet).

Finally, a title may provide a specification (e.g. a operating context),a reference to a specification (e.g., a link to the operating context,skin, or style sheet), or the identification information of aspecification (e.g. a operating context, skin, or style sheet searchspecification, or parameters to a search service) that specifies thedesired components, bindings, and look and feel desired. Alternatively,a title may provide a unique identifier that the Active User interfacemaps to a defined configuration (e.g., an identifier for a provider ofchild content that defines a specific operating context, skin, or stylesheet) to be used when processing rights associated with that specifictitle.

In an example embodiment, the User interface provides an applicationuser interface that comprises two panes. A first pane is provided as themain screen for the User interface, as shown in the accompanying screenshots. A second pane is provided for use with task-specific details. Inone embodiment, the pane is displayed using a metaphor of a “pull outdrawer”. An example of the second pane in an extended pull-out drawer isshown in the accompanying screen shots. The pull-out drawer metaphorshows how the screen real estate may be changed based upon the amountand type of information to be displayed. The pull-out drawer is shown aspulling to the side, but may be alternately configured to pull outbelow, above, or to the right of the first pane's display. Additionally,a plurality of drawers may be provided, optionally pulling out on thesame or different sides of the first pane.

In an example embodiment, plurality of panes may be used to displayinformation related to specific content. In the example shown in theaccompanying screen shots, a second pane in a pullout drawer is used aspart of a title manager interface to display the workflow actionsembodied within a specific title and to provide the user interface forthe actions described within that title.

The User interface provides a “trust indication” that indicates that theUser interface is in secure communication with its underlying services,and that the loaded display components have been verified and validated.The trust indicator preferably will take the form of a lock symbol, asis common on web browsers to indicate a secure connection, but may beany symbol that the user understands indicates that the processing istrusted.

As shown in the accompanying screen shots, a title's rights arepresented to the user as a set of buttons that permit the exercise ofeach right in the “drawer” display pane. The user interface presented onthis pane is dynamically generated from information present in a titleand within the title expressed right operating environment.

In such embodiments, the User interface associates specific rightspresent in the title with features of the UI. For example, a “Buy” rightmay specify a specific input that must be gathered, have specificprerequisites, and identifies a service that should be invoked in orderto process the right. For example, a operating contexts style sheet mayspecify one or more style and layout elements that the right will bedisplayed in. In one example, the operating context may specify thatrights described in a title are displayed in the “drawer” pane. Therights specification provides optional additional display guidance withits attributes, which includes positioning and display guidance. TheUser interface uses these attributes, along with UI specifications fromthe operating context, to construct portions of the user interface,including the name, description, layout, text, underlying User interfacecomponent, application component, or service to be called when this UIcomponent is accessed for each portion of the UI. In some cases, thesefunctions are handled by the Controller application component, or anexternal service. The resulting user interface may thus be dependentupon the specification contained within a specific title, as well as thespecific title expressed right operating environment in use at aspecific time. In some title expressed right operating environments, notall rights for a title may be displayed. Optionally, some rights may bedisplayed on alternate screens, or they may be hidden in scrolling areasof the UI.

An advantage of this approach is that the User interface providesimproved support for rights-based commerce, where a user can operatewithin a specific rights-based operating environment. The operatingenvironment may convey the desired look-and-feel to the user, down toproviding mouse-over and context-sensitive help, and merge thisinformation with the information provided for specific titles andrights.

The User interface, operating within the context of its title expressedright operating environment, may process at title by:

-   -   a. selecting one or more rights from the title.    -   b. optionally combining the rights information present in the        title with additional information from the title    -   c. optionally combining the above information with additional        information from external sources.    -   d. Using the combined information to render a user interface    -   e. Processing the user interface by interacting with a user    -   f. Executing a specified distributed workflow step on the basis        of the interactions with the user.

Step a may be performed by selecting one or more rights from a specifictitle, and selecting some or all of them to be included in the UI. Theselection may be based, in part, upon information provided with therights in the title.

Step b may be performed by combining the selected rights informationwith additional information provided in the title, or using informationreferenced by the title. For example, the title may include a copy ofapproved graphics and description of the work represented by a title, orit may include a link to that information.

Step c may be performed by combining the aggregated information fromexternal sources, such as information provided by a storefront, from thetitle expressed right operating environment, or from third-partysources.

Step d may be performed by applying the user interface specificationsdefined in a operating context, view, or style-sheet, and rendering auser interface on a specified display pane.

Step e may be performed by processing the user interface, collectinginformation that the user enters, and optionally verifying at least partof the information.

Step f may be performed by the User interface calling one or morespecified User interface components or external services in accordancewith a specified distributed workflow. An example of a specifieddistributed workflow is provided by the service element in a rightspecification, alternative distributed workflow specifications may beprovided within the title expressed right operating environmentspecified by a operating context.

In one embodiment, the user selects a right they wish by clicking on abutton presented in the user interface. The mapping between a userinterface component, application component, or external service and aspecific button, as well as the button label, help definitions, andmouse-over text, is performed as described above.

6.4.2.2 Title Publishing Application

A title publisher is a TPE application that performs the tasksassociated with publishing (that is, creating new titles) and optionallymakes those titles available to users using a title manager, serviceregistry, title enabled storefront, wallet, or other title based storagelocation. Typically, alternate storage mechanisms are managed using atitle manager application. The title publisher provides an easy to useinterface for a user to identify, organize, and group new content (orservices and resources), and then generate a new title object, titletemplate, or other title materials that enable access the specifiedcontent, services, or other resources. Specific implementations of atitle publishing application may be produced, each optimized forcreating and publishing specific types of title materials withoutdistracting from the scope of the description.

Using a title publisher, title materials can be generated on the fly andimmediately by the title publisher which would then invoke the titlemanager to store the newly generated titles. Alternatively, the titlepublisher can generate new title templates that would describe thecontents of the title but would not immediately generate a title. Titletemplates could be used in a variety of ways by the content publisher,for example by the content publisher's online shopping site toautomatically generate titles when a buyer purchases new content. Thecontent publisher stores work in progress (such as grouped publishingefforts) in a data repository using the data abstraction portion. Titlepublishers may provide sophisticated functionality to enhance the onlineexperience for content publishers such as organizing content and titlepublishing into projects, sharing projects, and allowing communityprojects. Workgroup and workflow capabilities can be built into thetitle publisher as well as creating single-user and multi-user versions.As an example, a multi-user version can be implemented by a consumeraggregator or service provider in order to perform title publishingactivities on behalf of a user community. Enhanced features may provideadditional value to people using the title publisher such as verifyingpointers to content files and resources, automatically obtaining icons,and even pushing titles and content out to servers.

An authorized user may use a title publisher application to publishservice definitions to a Service Resolver and Registry. When thisoccurs, user uses a service mapping template (e.g.(/tts/src/xslt/tps/merchant/Services/ServicesCatalogToProducts.xsl), aservice definition XML file that and describe one or all services thatare to be loaded into the Service Resolver and Registry. This includesthe name of the service, and other specific details such as callingparameters that is used by the Service Router and other applications.The title publisher creates titles that describe each service, and makesthese titles available in the Service Resolver and Registry.

An authorized user may use a title publisher application to publish anoperating context definitions to a Service Resolver and Registry. Whenthis occurs, user uses a mapping template that defines the operatingcontext, a definition XML file that and describe one or all operatingcontexts, components, external services, configuration information, andother materials that are to be loaded as part of the operating context.The title publisher creates an operating context that describes thesematerials, and makes the operating context available in the ServiceResolver and Registry.

An authorized user may use a a title publisher application to publishone or more alias associations between a defined alias and anotherdefinition in a Service Resolver and Registry. When this occurs, useruses a mapping template that defines an alias, a definition XML filethat and describe one or all operating contexts, components, externalservices, configuration information, and other materials that are to beloaded as part of the operating context. The title publisher creates analias that describes these materials, and makes the alias available inthe Service Resolver and Registry.

6.4.2.2.1 Rules Builder

A rules builder module performs the task of building rules to beassociated with the titles and processing of the titles. The rulesbuilder module may provide an easy to use interface for the user tocreate and build rules that can be embedded within a title or usedduring the processing of a title. Rules that are not embedded within atitle may be stored in a data repository using the data abstractionportion. The rules builder may provide an extension capability to applyrules developed external to the rules builder ensuring the adaptabilityof title processing.

The rules associated to the title are developed and applied by thecontent publisher and by the user (or someone acting on behalf of theuser). The title management and title publisher modules may provide anapplication and interface to easily develop and apply rules to thetitles. For example, a content publisher may apply usage rulesapplicable to the title and the digital content and/or resource itprovides evidence of rights to. In turn, a user may apply default ruleswithin the title management module to assist in controlling andprotecting their actions related to certain titles (for example, toprevent from accidentally trading a valuable title). In another example,a parent may establish restrictions on the type of content their childmay access and use in their title management module.

Specialized rules, called triggers, may also be used. Triggers are rulesthat invoke actions that are external to the title management apparatus.For instance, a parent can be notified by email that a child wishes toredeem a digital content file for which there is some age restriction.

Specialized rules, called timers, may also be used. Timers are rulesthat invoke actions based on a specific time or based on a spent amountof time. For example a title may only be good for twenty four hours, oran exchange may only be valid for one week. Timers maybe combined withtriggers in rule processing.

6.4.2.2.2 Rating System

The content rating system can be used by publishers to determineappropriate ratings for their content, and these ratings can be enforcedby title management and resolver apparatus to ensure guardian approval.Content rating is an element within the content element to convey arating regarding the suitability of the content. The rating system isdependent on the type of content and the regulatory factors involved(e.g. music, video, movie, etc.).

6.4.2.3 Title Transaction System (TTS) Application

The title transaction application is a TPE application that verifies theownership of the titles by the users and selectively permits the titlesto be transferred if such rights are allowed. Among the modules that maybe contained within a TTS application are the following:

6.4.2.3.1 Title Manager

A title manager module performs management functions on titles such asorganizing, deleting, adding, transferring, trading, copying, backingup, viewing, and redeeming. In addition to basic title functionality,the title manager module can provide sophisticated and value-addfeatures to allow the user a better online experience such as chat wherereal-time redemption and trading are available during the chat session.Furthermore, features such as sorting categorizing, searching and notifycan be made available to the user. As an example, a sophisticated searchcapability can be implemented whereby the user can search the networkfor other users, titles available for bid, transaction makers, or even asecure and trusted third party lockbox with which to conduct a trade.This sophisticated discovery process may be an integral part of the TTSecosystem. The title manager module is the primary application componentthat the user may interact with on a regular basis. The title managermodule maybe designed to be a single-user or multi-user applicationdepending on the specific use of the module. A single-user version canbe used in a peer-to-peer network, whereas a multi-user version can bedeployed with consumer aggregators.

The title manager implements a lockbox feature that is responsible forsecurely executing trades between two parties. The lockbox providesstorage for titles being traded and provides a secure environment whereusers can verify trades, view samples, and accept a trade. Uponacceptance of the trade by all parties involved, the lockbox may executethe trade and provide each party with an updated title and stubobject-pair that evidences their new rights. The lockbox feature of thetitle manager can be implemented as a standalone service so that atrusted third party can provide secure execution of trades.

6.4.2.3.2 Digital Lockbox

Title trading is supported by the title technology and the applicationsthat process titles. Trading between parties can be accomplished in manydifferent ways and involve any number of technologies and techniques.According to one example, a digital lockbox component is used as asecure container for the title objects that are being traded between aparty A and a party B. The digital lockbox component includes two secureareas that contain the title objects for trade, party A's title objectsare stored in a first “drawer,” while party B's title objects are storedin second “drawer.” The digital lockbox component further permitsinspection by either party into the contents of the lockbox in order foreach to verify the title objects and approve or cancel the trade. Thedigital lockbox component would not permit ownership to be transferredand only permits viewing of sample content, or of the content permittedby a redemption method (e.g. content legally shared). When both partieshave confirmed the trade and approved of the title objects, the digitallockbox component claims ownership over all title objects in thelockbox, and then transfers ownership to the respective party.Transferring ownership involves delivering the title objects to theappropriate title managers and subsequently having the title managersclaim ownership for their respective party. The digital lockboxcomponent in this case is similar to a 3^(rd) party escrow system byproviding a substantial level of guarantee to both parties involved inthe trade. For instance, if any part of the trade failed during theclaim process, the digital lockbox can rollback the entire trade. Thedigital lockbox can also provide a legal record of the trade to allparties involved in the trade. It should be noted that, the contents ofthe trade can be one or multiple title objects.

In another embodiment, a digital lockbox component supports a transferin which party A intends to give party B the title objects with nothingexpected in return. For example, party B could sample the content andreview it before accepting the transfer. The claim process for the titleobjects would remain the same and the digital lockbox component canprovide a record of the transaction. In yet another embodiment, thedigital lockbox component can support: multi-party, dependent trades,nested-trades. In yet another embodiment, the digital lockbox componentmay support complex trades involving service level agreements,insurance, legal recourse, guarantees, and content introspection. Forexample, a highly confidential trade can be implemented with specialcontent inspection rights provided through the digital lockboxcomponent. This would provide both parties with the ability to view theconfidential content for the duration of the trade negotiations underspecial circumstances, such as viewing directly using a controlledapplication similar to that provided by digital rights managementsoftware.

In another embodiment, a simplified trade can be executed directlybetween two parties by having the title managers simply transfer thetitle objects and subsequently have the receiving title managers claimownership over the respective title objects. In yet another embodiment,a trade can be executed directly by the title managers acting as secureagents. An established protocol can be used by the title managers tosecurely trade the title objects. For example, a Boolean circuit can beutilized by the title managers. In another embodiment, securityownership indicia associated with each title object can be updatedaccording to specific title authentication techniques employed by eachrespective title object.

6.4.2.3.3 Transaction Tracker

A transaction tracker module performs the basic task of tracking allinbound and outbound transactions whether successful or not. The trackermodule is configurable by the user to determine the level of tracking tobe performed based on the user's requirements. The tracker may be usedto provide a record of all transactions performed by the user such astrades and transfers. The tracker may be used by all core TTS componentsfor creating a record of all transactions (for example, those performedby the title resolver and content publisher). The tracker may recordtransactions in a data repository using the data abstraction portion.

A component of the title system is the transaction tracker. Thetransaction tracker is a module that can track all aspects of titleprocessing. As the transaction tracker “sees” titles being processedduring the course of a transaction it can invoke system rights embeddedwithin the titles to activate additional tracking logic, e.g.,generation of specific reports. The publisher or issuer of a title canput tracking rights in the titles they publish which can be picked up bythe transaction tracker, thus allowing remote monitoring andnotification. Such implementations involve the processing of titleswhich include rights, some of which are system rights which enable thetracking function.

According to some implementations, the transaction tracker systeminteracts with all the components of the system that process titles. Inthis embodiment it would be a title publishing system, a title resolversystem, a title based payment system, and the title manager; in otherembodiments it could be other title enabled systems, for example thetitle helper, the market maker, or the title search engine. In otherembodiments of the invention the transaction tracker system may not be acentralized solution, but an additional functionality of the individualtitle processing component, or it maybe a combination of both acentralized and distributed system. The transaction tracker system isresponsible for tracking and recording the events that occur on thetitle. These events could include publishing a title, redeeming a title,sharing a title, or storing a title in the title manager. Thetransactions and the information that is recorded are dependent upon theimplementation and requirements of the system.

In another embodiment, the transaction tracker system can monitor theprocessing of all titles and execute tracking and monitoring rules asexpressed by the titles. In this example, the tracker can invoke certaintracking rights (redemption methods) in the title as the title isprocessed or communicated. This allows the issuer of the title toprovide additional monitoring over the use of the titles they haveissued. As a further embodiment, the rules processing can be executed asa background task or even as an asynchronous task on a separated andconnected system, without impeding the processing of the title.

A report generation system is responsible for taking the collectedtransactions and processing that information to generate the reports.The mechanism for generating these reports will be dependent on theactual implementation, but they could be a function of the database thatstores the transaction records, a report generation tool, or as afunction of the title system itself.

According to one embodiment, the title tracking system records anyinformation that is stored in the titles that are processed by the titlesystem. Depending upon the configuration of the title tracking system,the information for a title may be recorded in its entirety in adistinct data record, or as part of the information in a distinctrecord; in other embodiments, the recording method for the titletracking system may process the tracking information directly, andupdate a summary record.

In another embodiment, the title tracking system may use informationwithin a title, to cross reference other information held within thetitle system. For example when a title is purchased, it could be crossreferenced to information that is held within the system, such thatpurchases of items could be cross matched to demographic information.

In yet another embodiment, the title tracking system, the informationthat is available from a particular user's title account can be used toreflect the information that is presented to the user. Of course privacyconcerns may have to be addressed in such an embodiment and mechanismscould be provided to protect privacy. These mechanisms could be simplepolicy based systems such as opt in/out policies, or the user could havea marketing profile title. The marketing profile title would be a titlethat allows the user to see and control the information that is sent tothird parties.

as providing an identifier for “free” use. Strong authentication may berequired for other instances and may be enforced by the ecosystemcomponents. Strong authentication can take the form of two-factor suchas Smartcard and PIN, or via mobile phone using a SIM card and a PIN, orvia any other supported method such as a SecurID token card. In basicform, authentication may be a username and password. Authorization mayprovide fine-grained access control to core TTS applications as well asto use titles within the ecosystem. Authorization may be based on rulesestablished within titles and configured as part of the implementationof core TTS applications.

A payment interface A rating system module performs rating tasks ontransaction records to support billing requirements. The rating systemmay be flexible to support the variety of billing options requiredwithin the ecosystem. The rating system may act on transaction data butmay maintain separation between the data sets to ensure integrity of thetransaction log.

A billing interface module provides an interface to the billing systemoperated by the user or entity running any of the core TTS components ormodules.

A transaction viewer module provides an interface for the user to viewtransactions recorded by the transaction tracker.

A synchronization & replication module performs synchronization andreplication across components and modules within the TTS system. This isrequired for a number of functions including (but not limited to)synchronization and replication of transaction log entries,synchronization of titles across title management modules in a highlydistributed environment, and replication of title databases to supportredundancy and high-availability. Synchronization and replicationtechniques are well understood by those skilled in the art and will notbe discussed further.

A cryptographic interface module performs symmetric and asymmetriccryptographic functions as required within the TTS ecosystem.

An authentication and authorization module performs the typeauthentication and authorization required by (and specified by) thetitle or other ecosystem configurations. Authentication may not berequired in certain instances, or can be as simple module provides aninterface to a payment system operated by a user or entity of the coreTTS components and modules. This permits real-time and batch processingof payment requests as configured by the user or entity.

A cache management module performs basic caching functions of thecontent or resources retrieved by the title system. This function mayprovide performance benefits using cached content versus retrieving newcontent on every request for the same content.

A user registration module performs registration of new users into thecore TTS components and modules. This may be used to establish new usersin a single user environment such as peer-to-peer, as well as establishnew users in a multi-user environment such as that hosted by a consumeraggregator. A consumer aggregator is an entity that provides services toa consumer base (i.e., ISP, mobile operator, etc.).

A transaction maker module performs transaction maker functions such asoperating an exchange for the sale of titles, perform licensing ofcontent represented by the titles, maintaining a book of trades, closingand clearing trade transactions, and performing additional value add asdetermined by the market.

An intelligent data retrieval and query module integrated with the dataabstraction portion in order to perform intelligent searches and querieson a variety of data in a variety of disparate locations. The IDRQmodule can combine, map, and match data before presenting it torequesting applications through the data abstraction portion.Persistence and caching can be developed into the IDRQ module to enhanceperformance on multiple and frequent queries/searches.

A web crawler module performs searches on the web to catalog content andprovide a mechanism to automatically generate titles that represent thecontent that has been discovered. The web crawler module can be usedstatically or dynamically executed based on configuration of theimplementation and/or on inbound requests. The web crawler module couldinterface with the intelligent data retrieval and query system attachedto the data abstraction layer for intelligent searches and retrieval ofweb content.

A discovery mechanism that can be used by all appropriate modules fordiscovering TTS resources that may be available on the network. Thediscovery mechanism may allow TTS modules to participate in apeer-to-peer environment as well as collaborate on activities. Thediscovery process can ensure that trust third parties are available forconducting secure transactions and well as simplifying the user andcontent publisher experience for clearing titles through the ecosystem.

While the invention has been particularly shown and described withreference to specific embodiments thereof, it will be understood bythose skilled in the art that changes in the form and details of thedisclosed embodiments may be made without departing from the spirit orscope of the invention. For example, reference has been made herein tovarious types of computing platforms, network configurations, protocols,and processes which may be employed to implement various aspects ofspecific embodiments of the invention. It will be understood that suchreference should not be used to narrow the scope of the invention.Rather, such references will be understood to be made by way of example,and it will be further understood that any of a wide variety ofcomputing platforms, network configurations, protocols, processes,computing models, and the like, may be employed to implement embodimentsof the invention without departing from the scope of the invention. Forexample, embodiments of the invention are not limited to specific typesof computing platforms or network devices referred to herein. To thecontrary, virtually any type of computing device having at least oneinterface for receiving or transmitting data (e.g., packets, frames,etc.), and at least one processor (e.g., CPU, processing cores,processor clusters, etc.) to facilitate processing of such data may beemployed to implement various aspects of the invention as will beapparent to those of skill in the art.

In addition, although various advantages, aspects, and objects of thepresent invention have been discussed herein with reference to variousembodiments, it will be understood that the scope of the inventionshould not be limited by reference to such advantages, aspects, andobjects. Rather, the scope of the invention should be determined withreference to the appended claims.

What is claimed:
 1. A computer-implemented method for implementing aworkflow in a network, the workflow comprising a sequence of operationsrelating to a set of services deployed in the network, the methodcomprising: receiving title materials comprising one or more of a titleobject, a component of the title object, or a reference to the titleobject, the title object comprising a digital bearer instrumentspecifying the workflow and representing at least one right relating toimplementation of the workflow in the network which may be redeemed bypresentation of the title object to a title-enabled device or processoperating in the network; and upon validation of the title object,implementing the workflow in accordance with the at least one rightrepresented by the title object.